Help with configuration for hidden and conflict files

Hi everyone! I started using Syncthing a few days ago to synchronize one folder between two computers, a Windows 10 laptop and a Linux desktop (where the folder is stored in a external USB hard drive). I was looking for a light and open source solution, and I am pretty happy with it so far. I however believe that I have not configured it correctly. The version is 1.22.0.

One thing is that when I open Libreoffice files, the hidden .lock file become visible in the folder. I do believe because the file is synchronized to Linux, where it loses its hidden status, and is synchronized back as a visible file in Windows. Moreover sometime it generates a conflict file of the now-visible lock file. How can I avoid synchronization of hidden files in the Windows 10 client?

The other issue is that sometimes it generates a conflict file of .svg files I edit with Inkscape on my Windows 10 laptop, when I am away from home, where the Linux desktop is and is turned on. So, if the Linux desktop is editing the files, it is not me, I guess it is some system background process. Do you know what may be happening and if I have to change the configuration of the client in Linux?

Thank you!

You can’t ignore hidden files specifically but you could add .* to your ignore patterns which will then ignore all so called dotfiles (which are usually hidden by default in Linux but not in Windows). Alternatively, just for LibreOffice, .~* or more specific .~lock.*# will take care of those lock files.

Thank you for your answer. I created a .stignore file in the root synched folder, that contains the line

.*

However, it still create the lock files. What am I doing wrong?

What do you mean by “it”? The files themselves will, of course, still be created by the office suite, but the idea is that Syncthing now won’t sync them between different devices, so there should be no conflicts between them.

Sorry, I meant that Syncthing was still synching the lock file. The lock file disappeared after closing LibreOffice, but was coming back visible few seconds after because of synchronization. I added the .stignore file also in the other device root synched folder (before I just added it to the folder in one device), and now it looks like they are not synchronized anymore. I will fully test it tomorrow.

And what about the conflict files? It generates them when I am using only one device.

Please update all devices to the newest version which is v1.22.2 at the moment. There were bugs in v1.22.0 and v1.22.1 that could lead to those kind of conflicts.

Hi Tomasz, I updated the Windows client version to 1.22.2 (the Linux version was already 1.22.2 due to apt-get upgrade). Unfortunately the issue is still there.

Sorry to bother you. I still have conflict files being generated with version 1.22.2. Is it possible to disable synchronization for files that are open by a program? For example, that as long as I am working on a file and I periodically save it, but keep it open, the saves are not synchronized until I stop working on the file and close the program (e.g. Inkscape).

Windows does that automatically by locking files in use, so Syncthing can’t access and sync them until they’ve been closed. The mechanism isn’t perfect though, and there are pieces of software that don’t follow the OS and thus don’t lock their files, so this is more of a case-by-case situation. There’s nothing similar on other operating systems as far as I’m aware though.

In other words, this can’t really be done in a reliable manner. You would need to add those files to your ignore patterns but then they won’t sync at all, open or not.

I cannot use an ignore pattern, as it would be the majority of files. This happens with Microsoft Office Suite, LibreOffice, Inkscape.

Also, actually Windows locks files from editing, not from reading. I can open a file and, while open, still copy it somewhere else. So Syncthing can still read the file while being open, and this is when the conflict file is generated.

I think the one thing that is still unclear here is why Syncthing creates those conflict files at all. This really shouldn’t happen unless you edit the same files on multiple devices simultaneously… Just opening them when Syncthing is running isn’t supposed to create a conflict file, that’s for sure.

I think some of the issues solved in 1.22.0 and 1.22.1 are still there. Happy to help if you need me to check what is happening. But I would need guidance on what to do.

Can you describe the exact steps you take in order to trigger Syncthing to create such conflicted copies? Preferable with MS Office or LibreOffice as I’ve got access to those and can try to replicate the problem here.

SETTING:

Computer 1 (editing the file): Windows 10, using LibreOffice 7.4.3.2, the files are on an SD card with NTFS filesystem. Syncthing is on the hard drive where the OS is running.

Computer 2 (idle): Debian 11, the files are on an external USB drive with NTFS filesystem. Syncthing is on the hard drive where the OS is running. The hard drive spins off using hdperm.

ACTUAL TEST:

  1. I open the shared folder on Computer 1, select a ODT file and open it with LibreOffice.

  2. I edit the file and save it. The file is kept open in LibreOffice. After 30 seconds I hear the drive on Computer 2 spinning and synchronizing the file. No conflict file appears. The HDD spins off.

  3. I continue to work on the file. I write very quickly (in around 15 seconds) random characters and save at least 3 times. The HDD on Computer 2 then starts spinning. The conflict file now appears in the directory on Computer 1.

  1. I saved once more the file. I closed LibreOffice. I removed the conflict file on the folder in Computer 1. After few seconds I heard the HDD on Computer 2 spinning and a new conflict file is produced on the folder in Computer 1.

The NTFS filesystem on Linux may be the culprit here. Please try to tick the “Ignore Permissions” box in the Advanced tab in the folder settings for all folders on both devices and then see whether the conflicts still appear.

Sorry for the late answer. It solved the issue. Thank you very much.