auanasgheps / snapraid-aio-script

The definitive all-in-one SnapRAID script on Linux. Diff, sync, scrub are things of the past. Manage SnapRAID and much, much more!
GNU General Public License v3.0
231 stars 37 forks source link

Files with zero sub-second timestamp and Syncthing #57

Closed nurunet closed 1 year ago

nurunet commented 1 year ago

Probably a stupid question, but what happens when the script is checking for zero sub-second files? I sync files from some machines to my OMV server, which uses Snapraid & MergerFS for the data drives.

I regular have Syncthing complain about "Locally Changed Items" on the server, and I am starting to believe this is due to the script. Last night, the script returned:

Checking for zero sub-second files. Found 12 files with zero sub-second timestamp. Running TOUCH job to timestamp. [Di 18. Apr 01:03:04 CEST 2023] TOUCH finished [Di 18. Apr 01:03:07 CEST 2023]

Today, I have twelve files in Syncthing with local changes. The files I checked are binary equal to the originals, so I guess the change must be in the "metadata". I switched off syncing of permissions and the such, so the time stamp remains a possible culprit.

Any way to prevent the script from changing files without excluding them from syncs?

auanasgheps commented 1 year ago

Hi, that's a good question!

In my experience, files not originally created on the server itself will not have a sub-second timestamp.

For example I sync files from Google Drive with rclone, and after every sync those files appear in that section.

The files I checked are binary equal to the originals, so I guess the change must be in the "metadata".

That's correct, SnapRAID does not actually change your files by doing this, but only touches the metadata that can see the OS, which differs by the OS and filesystem.

"Checking for zero sub-second files" is the snapraid touch command, here's what the manual says:

Sets arbitrarily the sub-second time-stamp of all the files that have it at zero. This improves the SnapRAID capability to recognize moved and copied files as it makes the time-stamp almost unique, removing possible duplicates.

More specifically, if the sub-second time-stamp is not zero, a moved or copied file is identified as such if it matches the name, size and time-stamp. If instead the sub-second time-stamp is zero, it's considered a copy only if it matches the full path, size and time-stamp.

Note that the second precision time-stamp is not modified, and all the dates and times of your files will be maintained.

If Syncthing is complaining about modified files, it's not SnapRAID fault. I use Syncthing a lot to sync data from and to my Android devices and don't have this problem, but I have disabled permission sync as you mentioned.

I hope this answers your question!