Closed brenthuisman closed 4 years ago
Also, do we provide any GUI options for handling or even viewing *.1
backups? Maybe an action category with delete/keep actions? See also #6.
Both orphaned par2 files and backups should be presented on the actions panels before removal, even if instructed to do so. Right now these removals don't show up anywhere, which would be useful to find accidental deletes.
In addition, for backups, we don't search for them explicitly (they'd just show up as new files). So we could assume any *.[0-9]
is a backup, assuming *
is an existing file. Or should we then assume a deleted file?
In summary, we manually create backup data verifiedfiles_repairable that we recreate anyway.
Fresh creates and verifiedfiles_err can't have an undo, and I think it's safe to assume when someone ticks the 'overwrite' box they know what they are doing.
Fixed.
Currently,
par2
creates a backup when you fix a file. When you overwrite parity data, you probably believe the original file was updated and the parity files would undo that update. However, you may not remember or be sure you updated the file, so even though you want to update the parity files, you may want to create a 'fixed' copy, a restored version of the file.This could be done by before recreated the parity files, repairing them (which, if keep_old is True) will restore the file and save a copy of pre-restored file (presumably the updated file) to
filename.1
. After this restore, we must thus swap filenames, and then recreated on the (oncefilename.1
) filename.Potential problem: the file turns out to be unfixable. In this case, just recreate.
In both the case of the restore and recreate scenarios, it could be an idea to handle backups ourselves. i.e. not rely on
par2
creatingfilename.1
.