So, I keep my code synced between systems using Syncthing. It works great. But there is this annoying issue where sync-conflict files keep popping up. Very very frequently, like multiple every 10 minutes or so.
As far I can tell this only happens when I’m actively working on a project in PHPStorm.
I’m guessing it has something to do with how PHPStorm autosaves, but I have not found any settings to tweak that make a difference.
Has anyone run across this before? Any idea how to stop it?
Thanks in advance!
Please provide more information on what kind of operating systems, file systems, etc. are involved. Also, please make sure that you run the newest version of Syncthing everywhere.
OS’s: Ubuntu 23.04 and Debian 12.
Syncthing v1.26.0 on the system I’m working on now.
The other systems should be within a version or two, I have the apt repo set up and update fairly frequently.
PHPStorm is version 2023.2.3.
FYI, this issue is not something new. I’ve been seeing it for months, maybe years. Just never felt annoyed enough to post about it until today.
I am pretty sure this particular sync folder should only be shared with systems currently on my LAN. My active instance is on a wired network with the Debian 12 machine, and then the other Ubuntu 23.04 is a laptop on the wireless.
Anyway, I’ll go make sure the other systems have the latest version of syncthing.
No problem, it was an obligatory question to ask, especially since distributions like Debian/Ubuntu are by default stuck using outdated Syncthing versions from their repositories.
What about the file systems? Do you use anything non-standard, e.g. NTFS on Linux? Also, are you 100% sure that only these two systems share the folder and there is no other device involved (e.g. something running Android)?
I double checked that only the three systems I thought I had syncing, are actually syncing my code. Just the Debian 12 desktop, Ubuntu 23.04 desktop, and the 23.04 laptop have the shared folder.
Your mention of file systems did make me wonder. Debian 12 is on ZFS. Specifically I have Proxmox running on it. (It’s my older main system that I just replaced this month with the Ubuntu 23.04 desktop.)
Both Ubuntu 23.04 systems are using ext4.
The other interesting thing might be the fact that I have my source directory mounted to a Docker container. The container’s process is using the same uid/gid as my host user, so it’s not something odd like uid/gid’s not matching.
FTR, all three systems use the same uid/gid for my main user.
Any of that raise any flags?
On another note, could it have something to do with inotify limits? On the Ubuntu 23.04 systems the
user.max_inotify_watches = 524288 value doesn’t appear unless I’ve just sudoed as root and then exited back to the normal user. I am running Syncthing as a
Right tool for the right job. Syncthing won’t ever come close to what a proper VCS like git will provide you.
And git would be the wrong tool for syncing files. git pull/push/fetch/etc. are not ways of syncing, they’re ways of managing changes in your code. git is not a sync tool.
Especially if you want to sync files that you keep in .gitignore. Like, say, dumps of a dev database. Or binary files, or any number of other things you should never commit to a git repo, but you do need to have available in your dev environment.
This is unrelated unless the limits prevent Syncthing from detecting actual changes, which then causes your modifications to sync with a delay, leading to the conflicts. You would see
ionotify-related errors being reported in the Web GUI if that was the case though.
i could be wrong but i think this comes from the way how phpstorm (auto)saves files…
there is an option called “Back up files before saving” (Appearance & Behavior → System Settings) that enables what used to be called “safe write”…
this will save your changes to a new file and once successful, deletes the old file and renames that new file back, at least thats how it used to work if i’m not wrong…
the current description reads like it copies the file, tries to save the current one, and if successful deletes that copy
there used to be a lot of issues with things like group permissions, hotreloading or 3rd party sync programs in the past, so my best bet is if you disable that option your issue will be solved