dCore Import Debian Packages to Mountable SCE extensions > dCore X86
Empty '.filetool.lst'
Jason W:
The backup functionality is the same in Core as dCore, but for changes to pathname prefixes like /bb versus /bin.
My thoughts are that the same basic functionality on this should be shared across Core and dCore, base functionality should only differ when absolutely necessary. So if we want to change this in Core we should in dCore, or vice versa. That way users can easily use on or the other and not have to change habits.
When I run the command that is used to tar up mydata.tgz, when I use full tar it just creates an empty archive when .filetool.lst is empty. When busybox tar is used, it just echoes an error of empty archive and no archive is created?
Is that not really the same end result? No data in an archive on reboot to unpack?
Rich:
Hi Jason W
--- Quote ---When busybox tar is used, it just echoes an error of empty archive and no archive is created?
Is that not really the same end result? No data in an archive on reboot to unpack?
--- End quote ---
When using the GUI to exit, failure of the backup causes the exit to abort.
Jason W:
Ok. The dc and ash errors are due to entries in filetool.lst that are non-existent.
Will take some hacking but some tests can be put in that will make it more error proof in the case of entries that do not exist. I am less concerned about an empty filetool.lst, but very possible for a typo in an entry in that case which the entry should be ignored by dc and anything that will make it bork.
I will work on this, and then if Core wants the changes it would be simple to plug in.
Jason W:
Ok, if there is even one entry in filetool.lst, tar errors occur and the backup status is echoed to /tmp/backup_status. Or if filetoo.lst is empty, empty archive error is echoed to that file.
Is that not a great degree of safety when one thinks they have made all the right entries in filetool.lst yet there is a typo or similar? Rather than have the reboot proceed and those files lost to the reboot? If there is a wrong entry in filetool.lst, then reboot will not occur by the graphical exittc which novice users will be using, giving them a chance to correct the entry/entries and save their data.
So what is the desired reboot behavior then if there are errors in the filetool.lst or it is empty? Reboot anyway and possibly lose data, or bork an allow the user to save his data and fix the situation. Or here are we only concerned if filetool.lst is empty and not concerned about errors in the file?
Rich:
Hi Jason W
Ideally, if there is an error in filetool.lst (leading backslash, non-existant file, etc.) then reboot/shutdown should abort. If filetool.lst
is empty, presumably it's because nothing needs to be backed up so reboot/shutdown should proceed as normal.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version