| Summary: | Colon character in bacup file names causes problems | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | iptom <tomphz> |
| Component: | --- | Assignee: | Adolf Belka <adolf.belka> |
| Status: | MODIFIED --- | QA Contact: | |
| Severity: | - Unknown - | ||
| Priority: | - Unknown - | CC: | adolf.belka, jon.murphy |
| Version: | 2 | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
| Attachments: |
The appearance of backup file names.
list1 list2 mc |
||
|
Description
iptom
2024-07-21 09:28:07 UTC
That's very interesting. As the : has been in the backup file for the last 5 years (since CU125) I initially struggled to see why it would cause a problem now. However when I looked much closer at the backup files I had downloaded and stored I noticed that all of them no longer had a : in the time. My Arch Linux system had replaced the : automatically with either a space or an underscore. With a space the filename was quoted to include the space. In both cases doing a restore from the WUI worked fine. If I copied those modified backup files back onto IPFire then the restore from the command line worked fine. However if the restore was done from a file that still had the colon in it then the tar command failed. If I replaced the underscore on the downloaded file with a colon and then did the restore from that file the restore also worked without any issue. So there seems to be a difference also between how the restore occurs between the WUI and the command line. It seems that most peoples systems could likely be removing the colon and replacing it with something else when downloading the backup file to another computer. Then most people doing a restore, also from the command line, are doing it with a downloaded file that has been copied back to the IPFire system and not with one that is stored on the IPFire system. That is the only reason I can think of that this has not been flagged up in the last 5 years. I do recall there was a user that raised an issue about the colon some time back (a year or two) but at that time I could not replicate his issue and probably had not noticed that my saved backup files had been altered when being saved. I just checked that if I had a backup file on my separate computer and replaced the underscore or space with a colon the file manager accepted that. Doing a restore from that file via the WUI seemed to occur without any issues. The change is easy enough to make. What I need to look at closely is to make sure that any restores from old backup files will still work. I think it should because the involved variable, I believe, is only used when creating the backup file and not at restore time. I have figured out why there is no problem if the backup file that is on a separate machine has a colon inserted and is then used for restore. The backup.pl code gets the backup file and saves it to the IPFire /tmp/ directory with the standard name of restore.ipf. Therefore the tar command is then being used on a file without a colon in it anymore. So it makes no difference if the colon is kept in the backup file name when being downloaded or not. The problem only occurs when doing a restore from a locally stored backup file via the command line commands. Okay, further information found. The colon is making tar think that it needs to operate on a remote location. There is an option in tar (--force-local) which will make tar operate locally even if there is a colon in the filename. This would seem to be the best option to go with as then the filename format stays the same, we just make tar work with that format. I will test this out in my vm testbed systems. With --force-local used for the tar extraction then the command line backupctrl restore filename-with-colon carried out the restore without any issues. I will make this change to the backup.pl file and submit it. I have identified why the downloaded version has the colon replaced by an underscore. This is Firefox changing this on the basis that colons can't be used in filenames. This is true for windows and MacOS but linux can use colons in the filename. Firefox applies this replacement for all characters that are considered invalid for filenames * < > | \ : ; ? / " and if these are used in the filename they will be typically replaced by an underscore. It would be interesting to know if other browsers do the same thing. The replacement of the colons by underscores seems to be a general thing with browsers. I have tested out Chromium and Vivaldi and both did the same thing. Probably makes sense to use the underscore in place of the colon but add the --force-local in to the tar command so when older files with the colon are restored on the command line then they will successfully restore. Created attachment 1579 [details]
The appearance of backup file names.
Look at the bigger picture. It makes more sense, logical and readable to use an underscore to separate the date from the time. (In reply to iptom from comment #8) > Look at the bigger picture. > It makes more sense, logical and readable to use an underscore to separate > the date from the time. I was re4ady to submit a patch update as I had built it and tested it out on my vm system with a range of backups with different formats. I will now look at vyour suggestion but that wilol delay things as I will now need to evaluate the system working with colon as the time separator, underscore as the time separator and underscor as the date-to-time separator with a dash as the time separator and make sure that all versions of potential backup files will restore correctly with that approach. That will take me a bit more time, especially as I have other things to work on in the following week. (In reply to Adolf Belka from comment #9) > That will take me a bit more time, especially as I have other things to work > on in the following week. >As the : has been in the backup file for the last 5 years (since CU125) I initially I think that if this error has existed for more than 5 years then one week will not make much difference ;) Regards Patch for fix created, tested and submitted. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/A3BQA5MEV26IPW4ZXJ34Z37TCBWMFKQJ/ https://patchwork.ipfire.org/project/ipfire/list/?series=4392 Suggested change for "NOW": I believe users will find it is easier to read a date like 2024-08-07_10.57 (with a period separator for time) vs. 2024-08-07_10-58. It is a small change but a helpful one for readability. @iptom - is this OK? The patch has been merged into next and will be in CU188 Testing @iptom can you please respond to @jon's question in comment 12 Created attachment 1596 [details]
list1
Created attachment 1597 [details]
list2 mc
@iptom I am not sure what your attachments are supposed to be showing. I thought at first that you had tried my patch and were getting some backups with an underscore after the time section but that can't be the case as you also have some dates with a dot between the hours and minutes. I think you need to supply some explanation for your attachments. (In reply to Adolf Belka from comment #16) > @iptom > > I am not sure what your attachments are supposed to be showing. > > I thought at first that you had tried my patch and were getting some backups > with an underscore after the time section but that can't be the case as you > also have some dates with a dot between the hours and minutes. > > I think you need to supply some explanation for your attachments. Thank you very much for the reminder. I tested the looks of the separators. Looking at the whole thing, I think the separator as a period is not so obvious because of the next dot after the time e.q. "Backup from 2024-08-21_14.19.ipf Size" "Backup from 2024-08-21_14-19.ipf Size" I would lean more towards this format “2024-08-21_14-19.ipf” But this is my humble personal separate (non-binding) opinion ;) Regards. Okay, thanks. Then I understand. The version with the dash between the hours and mins is what is currently merged, although it still can be changed during the testing phase. Will wait to see what @jon's response to your input is. A thought that has come to my mind, how do windows computers deal with multiple dots in a filename. I don't own one so have no idea. Linux can handle multiple dots in a filename. I can't test how a windows computer would deal with a backup file downloaded, via a browser, that had two dots in the filename. Do either of you have a windows system that could be used for the test? (In reply to Adolf Belka from comment #18) > Do either of you have a windows system that could be used for the test? no windows for me.(In reply to Adolf Belka from comment #18) > Will wait to see what @jon's response to your input is. I prefer the period and I will defer. Leave as the dash. |