Originally Posted by micksh
Restored about 10% then SnapRAID stopped with error:Error opening file 'D:/Data/Downloads/bb data/AUTORUN.INF'. Permission denied.
DANGER! Without a working data disk, it isn't possible to fix errors on it.
Stopping at block 586869
This file has read-only, archive and hidden attributes. SnapRaid didn't complain when it created parity and I didn't change my data.
Yep. Not having permission to write a file is an unexpected error for SnapRAID, so it stops the processing, expecting you to revert the stop condition.
This is a safe measure, likely too strict in this case, to prevent to make more damages on a faulty HD. For example if a file commands fails because the HD is not working properly.
A better approach in this case is to exclude hidden files in "sync", and in "fix" remove the read-only attribute if needed.
This is for sure a new feature I'm going to add.
Two questions regarding this:
- Does SnapRAID open original data files for read-write? If it is so, I find it dangerous. There should be no reason to open supposedly read-only data for writing.
Files are opened in read-only mode in sync/check, and in read-write in fix. In fix a write may be needed to fix the file, so it's opened also for write.
But in fact, it may make sense to reopen them for write if needed.
- If some small file in original data set is damaged (due to bad HDD sector or accidental deletion) will it prevent me from restoring most of my data?
There are two kind of errors for SnapRAID. Data error are always fixed, and if not possible skipped continuing the processing. HardDisk errors are instead stop conditions, especially in the fix command. The rationale is that if the HD is failing, it's a lot better to try to copy all the readable data from it, instead that trying to fix on it.
So, if you delete a file, or it contains wrong data, the process will continue even if SnapRAID is not able to fix it.
But if the OS is reporting an error in a file operation, the process stop to allow you to address the problem.
In other words, one original data file is lost, this invalidates block(s) of parity, this makes impossible to restore files that overlapped with now invalid parity block(s).
This is expected, but I thought everything else that still has matching parity and good original data should be restored.
Is it the ultimate design goal?
Sorry for the late answer, I was out for holiday in Tuscany near Siena