Allyn Malventano - 2020-06-22

If a drive has just one folder present in its SnapRAID path and the contents within that folder were modified, SnapRAID throws a warning and fails to begin sync, as it believe that 'all the files present have been rewritten' when in reality that is not the case. Yes, the only directory present in the root had its attributes changed, but the contents of the drive are not all rewritten (in my example only a few files were moved around and none were deleted at all). Since SnapRAID had already scanned the whole drive by this point, it should be aware of this actual minimal change to the contents and not throw the warning / require a restart with --force-empty sync. It also makes no sense to ever have to use --force-empty sync on a path with 11TB of data present.

Those who are scripting SnapRAID will have to include this flag or else their syncs will frequently fail to start, which increases risk for the case where a drive is actually missing or unexpectedly empty. It also risks decensitizing people to the real cause for this error if they must always call SnapRAID --force-empty sync.

Scanning disk h23...
Scanning disk h24...
Scanning disk h25...
WARNING! All the files previously present in disk 'h04' at dir '/z/h04/z/', disk 'h05' at dir '/z/h05/z/', disk 'h06' at dir '/z/h06/z/', disk 'h07' at dir '/z/h07/z/', disk 'h08' at dir '/z/h08/z/', disk 'h09' at dir '/z/h09/z/', disk 'h12' at dir '/z/h12/z/', disk 'h14' at dir '/z/h14/z/'
are now missing or rewritten!
This could happen when some disks are not mounted
in the expected directory.
If you want to 'sync' anyway, use 'snapraid --force-empty sync'.
root@BB-8:/dev/mapper# ls /z/h04/z
media
 

Last edit: Allyn Malventano 2020-06-22