Rysz

This also depends on if your filesystem supports sub-second timestamps. https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond Ext4 only supports nanosecond timestamps if the inodes are 256 bytes or larger. The default inode size of mkfs.ext4 depends on your distro. Some "low-power systems" distros still use 128 bytes to save disk space. And some other distributions also have the rule that "if the partition is smaller than 512 MiB, use 128 byte inodes".

Hello! Since your parity disk is broken, I would just replace the broken disk with the replacement disk and see this as a normal disk recovery. Afterwards I would run: snapraid fix -d PARITYNAME to recover the parity. Then make sure your files and everything are there, then run a snapraid sync. The procedure you linked is mainly for replacing a working parity disk with a (bigger) one. This is the relevant part for you: If you have a partially damaged or totally lost parity file, you can run the "fix"...

Hello! Since your parity disk is broken, I would just replace the broken disk with the replacement disk and see this as a normal disk recovery. Afterwards I would run: snapraid fix -d PARITYNAME to recover the parity. Then make sure your files and everything are there, then run asnapraid sync. The procedure you linked is mainly for replacing a working parity disk with a (bigger) one. This is the relevant part for you: If you have a partially damaged or totally lost parity file, you can run the "fix"...

It seems that you already built some kind of implementation for SnapRAID within your specific niche use case and that's great. But what you're describing seems to be more of an ecosystem around SnapRAID, rather than features that I could personally see being that useful when added to the program. That's the beauty of SnapRAID, it doesn't force anything on you, but lets you use the tools of your choice around it... for some that's mergerFS, for others that's simple Bash scripts, for you it's PowerShell...

Next time instead of manual comparison you can just run a SnapRAID check on the file in question, if it comes back OK then the content is identical and you can sync the timestamp change.

P.S. If you do not want to sync, you can also delete the file and run a fix on the file afterwards. That will recreate the file with the old timestamp and a diff will show no differences even without a sync - as timestamp and content will now be identical to the previous sync state.

No, if the file didn't change content-wise (hash-wise) and only the time-stamp did (the time-stamp not affecting the hash) there's nothing to fix (as the file is identical to the last sync state content-wise) but the file will still show as updated until you next sync because diff checks time-stamps and not file content (hashes). If you run a check on the file it'll come back as OK if the content is unchanged, even if the time-stamp is different. So you need a sync to apply that timestamp change,...

Honestly, I think something went wrong here. A fix should revert the file to the state of the last sync - this would include the timestamp and a diff shouldn't show any differences after a fix (as the file should be identical to the last sync state after fixing... the diff comparing to that last sync state as well after all). The whole point of fix is to make the file hash-identical to the last sync state. Whenever I fix files, no diff is shown afterwards and certainly no sync is needed (unless I...