Can’t edit because it’s too similar - but to clarify: VSB is set to false.
1 Like
I think I know the problem, at least I found a bug related to the error message you got. If I am right, then it means that those files were modified without changing size and modification times. This means either there is a program doing weird stuff when modifying these files (e.g. first setting size and modtime, then later writing the actual data) or those files changed due to disk corruption. Unless you know about such a program, make sure you have a backup or create one from the data on the unsynced devices.
If my hypothesis is right, touching (or whatever is the equivalent on your system that sets the modification time to now without changing the file itself) the affected file on the source and rescanning should fix the problem.
Thanks very much - really appreciated!
Compared with the previous version of the file, the size and modification time are different… But I realise this might not be what you’re talking about!
The files in question were WAV files created by Apple’s Logic Pro X audio application; it’s possible that this does something unusual about pre-allocating the file before writing the data - but Syncthing is successfully syncing thousands of other files generated by this app, so I don’t think that’s likely.
That’s possible (and I do have backups thankfully) - but both the ‘old’ and ‘new’ versions of the file open and play as expected. But of course, it may only be a metadata chunk of the file which is affected by a corruption.
Sure. I’ll try that on a candidate file or two next week to ensure it goes smoothly, before applying it to all the outstanding files.
Thanks for your input; I appreciate that 39 files out of 132,000 (in this shared folder) is small fry and (hopefully) easily corrected - but I just wanted to give chance for any glitches to be identified before I wipe the evidence!
Puuuh, I was quite happy to read that, in the beginning of your post I thought I might be wrong all along, but that does sound somewhat plausible. The success of other files is probably, because for this bug to hit, the change must have occurred at the very end of the file, the rest of the file must have been the same. And in addition even then, it is still racy: The program preallocates, Syncthing gets an event from the filesystem, then waits for 10s to scan. Now if the program does the “real change” within those 10s, Syncthing will see the correct data, if it does so afterwards, it doesn’t.
Sounds like a good plan. Given the above, that the file is working and you having backup, there really isn’t much risk.
Thank you for that and in general for your responsive and very clear reporting, especially after the long silence on my part!
Hello:
That’s quite possible - looking at the file diffs and running a test just now, it looks like Logic is creating a graphic overview for the WAV file, then writing this to the end of original file, leaving the rest of it unchanged (save for a couple of bytes near the beginning). In doing so, it appears to be not updating the Modified Time of the file.
Sounds like my best bet is to back off the Fs Watcher Delay to give chance for the file to be completely written before it gets hashed - but it brings up an interesting question: what happens in Syncthing when an application updates a file without updating its Modified Time?
That or waiting for v1.1.3 (or v1.2.0), which is a bit of a stretch. And report to Apple/Logic devs that their program should behave nicely when changing a file 
Syncthing recognises a change when either size or mtime changed. If both don’t change, nothing will happen until a remote either sends a change or request the file. In both cases Syncthing will then notice that the data on disk is not what is expected and will thus rescan, which is fine for a request and creates a conflict for the remote change. That is, except for the corner case you found and is fixed in the linked PR.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.