Hi. I’m not finding the answer to this question. If some apps are holding locks on files, will Syncthing grab a copy of them? (Using the Volume Shadow Copy method… or something else?)
No, it uses standard Go APIs for opening files, which I suspect does not cover what you are talking about.
That seems correct. I tested a file edit, saved and kept the file open and it would not budge until I closed the file. So I can’t use it. Bummer. Not only that, but Syncthing actually locks the file itself, so it would cause failures to the application trying to use the file while it’s syncing.
It does not.
OK. Well, after I closed the file, and while Syncthing was doing its initial scanning of that file, picking up the fact that it changed, I was not able to lock the file until it was done. The error I was getting was that it was opened by another process. But as soon as Syncthing finished, I was able to open the file. This was testing just in a PowerShell command: $file = [System.io.file]::open(“testfile”, ‘Open’, ‘ReadWrite’, ‘None’)
You’re setting sharemode None. That means that you’re telling the system that you don’t want to open the file if anyone else has it open. Not that Syncthing is locking it. Syncthing (via Go) uses sharemode ReadWrite.
Well yes… I was testing the worst kind of application locking. But ok, it’s not locking the file… it is opening it, preventing any application that wants an exclusive lock from working. Until Syncthing uses something like Shadow copying, it won’t work for any apps running and using files exclusively.
That’s correct. Those apps probably don’t work very well with bidirectional syncing in general either, so Syncthing might not be the tool of choice. For other things like SQLite databases this is a feature (one of the points of file locking, after all), as it makes sure the sync happens when the file is quiescent.
So can we add a feature request to add the ability to use Windows Shadow Volume (or whatever) to be able to read files as soon as they are saved?
Sure, but it goes straight into the “nobody cares to implement” pile, so if you want to make this happen, best you back it up with an implementation, as otherwise it’s as good as not raising the issue at all, as I suspect nobody will address it.
ok. 
I’m quite surprised nobody cares here (apparently). There are tons of file sync apps out there and at least half of them if not more address the issue of copying opened files.
I’m extremely skeptical of the utility of this. If an application locks a file against other readers it is generally because the file is in an inconsistent state while open and other readers should stay away because the contents doesn’t make sense. That’s what this kind of locking means. If this is not the case the application should instead use read shared locks.
Reading the file anyway via the back door and syncing that to other devices does not seem desirable to me in any way at all. Much better to wait until the file is available for reading in the normal manner, and presumably in a consistent state, and then sync that.
2 Likes
I know it’s ideally desirable, however it provides a way to make snapshot backups of apps (that you don’t have control over) such as even databases (though I wouldn’t use it for that). We struggle with apps that simply hold files open even though they are done saving. My plan is to run the update just overnight (at which point the files are “safe”) but it saves the headaches when users have the files open through the LAN. Many times it could even be things like Word or Excel docs that are saved but you can’t back it up because the user has the program open. You’re a sitting duck if you wait for the file to be released.
Use some other magic thing to copy the files into a separate directory periodically and sync that.
That is exactly what I’m setting up now.
I have following problem. I read this thread but not sure if about solution, or how to handle situation like this:
windows PC1 has open file one.pdf {only reading it}, that file is in folder_A which contains also file two.pdf
windows PC2 is rename folder {fodler_A -> folder_B}
after while on both PC I see folder_A contain one.pdf and folder_B contain two.pdf.
after closing pdf reader on PC1 situation remain, both folders are still sitting there.
thank you for help / tip how to solve this
Files (or folders) in syncthing are not renamed, but usually copied, so this should either result in an out of sync (until the files is closed) or duplicates until the file is closed.
that’s ok
what I am trying to say is that user Bob doesnt know that user Alex has open file on another PC while Bob is rename it. After while user Bob see duplicate file, he doesnt know what is going on, maybe he will delete it …
I am running syncthing.exe and managing over web, maybe I should install https://github.com/canton7/SyncTrayzor/releases/tag/v1.1.18 on windows so USERS get some notifications and tool how to solve problems. What you think
Definitely a good idea, SyncTrayzor integrates Syncthing very well into Windows and also has additional handy features.
About your use case: If the file that is “blocking the rename” is not modified, it should be deleted as soon as it is closed (and exists at the new location). If it was modified, both files (old and renamed) will still be there and there is not much that can be done there, as renamed files aren’t linked in any way in Syncthing. The current behaviour seems good to me, as it preserves all data.