Stuck as Local Additions with long paths


I have observed that when a only receive folder has very long paths, some of them get marked as “Locally Changed Items”, and so they remain no matter how many times you push “Revert local changes” button.

The files are right, all the data is synced without problem, even in those long paths.

As it could be due to the local filesystem not being able to show some of their properties, I configured the paths of the folders with the long path prefix: \\?\ + path in order to tell windows there are long paths. No changes. Still Local additions but well synced.

Environment: Windows for only send device and windows for only receive



What file systems are your folders located on, on both sides? Also, which versions of Windows are you using?

Syncthing should deal with long paths as they are. At least it does in my case, and I do have some crazy long file names, which cannot be normally modified either from Explorer or CMD.

Not sure if relevant, but may be worth checking:

You definitely do not need to specify anything to support long paths.

1 Like

I’m going to chip in and say that for the most part, long file names are supported. However I have had a couple of instances where St pops up access is denied* when handling files in the stversions folder. In order to clear the error I have to manually delete the query file(s).

Next time it happens I will add some screen shots, but it is a rare thing.

*It’s not permissions as I have checked / updated / set as everyone / took ownership and had no problem doing file operations on the files manually.

Sorry, but I am failing to see how your stversions permission issues are relevant to the issues of local additions being discussed here.

Are you implying it might be a permission issue for the local additions?

1 Like

Possibly related since St would be trying to move a file from the live sync folder to the stversion folder when it fails, but I reiterate it’s a very rare occurrence.

@ areyal, are your receiving folders compressed? Whilst St does support compressed folders, I have been spending the last week uncompressing mine as I am starting to wonder if issues I get with large files are due to compressed files.


The filesystems are both NTFS, being the send only folder in Win7 and the receive only folder in Win10

Tried what tomasz84’s link says in the W10:

Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem > Enable Win32 Long Paths It was in “not configured” state, settled to “Enable” No changes so far.

I had already done what terry says: delete the long paths and resync. All the data is then copied again without any issue, but the long paths come again as Local Additions. Curiosly it only consider local addition to the directories names, not the files inside.

Every time I press “Revert Local Changes” syncthing log register: Revert: directory is not empty; files within are probably ignored on connected devices only

Anyway this isn’t a big problem, data is correctly synced… but can mislead to think there is some issue with it.

By the way, receive folder was NTFS compressed, which it is now decompressing. If this solves the situation I will let you now, but I doubt this was the cause.

Thank you all for your feedback

As long as Local Additions only pops up for long path directories, and Syncthing logs as folder not empty when “Revert Local Changes” is pressed, I’m starting to think this is due to Syncthing having problems to verify these long paths directories as synced, but not having problems with the files.

¿maybe Syncthing index way for storing directories? index-v0.14.0.db

Try enabling ignore permissions, I somehow recall someone had a similar problem, very recently, so perhaps you can find something in the search.

I think I found the thread with same issue that you cited: this

Just for update:

Nothing worked: permissions, uncompress folder, remove folder and readd it, activate long paths in Win10 group policy (now I doubt this has to do with long paths, since I found one short). Instead, I found that some files inside the directories with problems are not being synced. Does not suffice to delete the directory but the whole branch must be deleted.

Moreover, global status is different in the two devices, which seems to indicate that the problem relays in the global index synchronization.

Send Folder, gobal and local status:

Receive Folder, global and local status:

When changed the receive only folder to receive and send, the status changed to synced, and when turned again to receive only, stayed synced without the files that where missed.
When a branch with missing files is deleted, it gets the directory structure and files that where not missed again, but no the missed ones. Definitely this seems to me that has to do with the index.

Syncthing 0.14.2

You can probably remove the folder and readd it on both sides, as the states should line up.

I think there’s still/again something odd with our sequence index causing unsent updates. I bet starting both sides with STRECHECKDBEVERY=1s would fix this without rescan etc. I saw something similar.

1 Like

[SOLVED] Hi again,

A complete index rebuild in the sending device by executing syncthing -restart-database solved the problem (took a long time), although this device didn’t show any problem :thinking:.
It may be easier to remove and then readd the folder in the sending device, as @AudriusButkevicius said.

Now the global status matches perfectly in both devices.

Seeing what @calmh proposes and looking at what STRECHECKDBEVERY does, it seems to me that solution could work, applied in the sending device or both, but I didn’t see it at time… :slight_smile:

Thank you all

[Conclusion] Trying to replicate this issue, I will describe the process that originated it, just in case some developer wanted a bit more feedback:

The sending only index was “broken” when a big folder was shared (>100GB, so a long time initial scanning is needed), and a bit later I added some exclusion paths, without waiting to the initial scanning finished. Moreover I restarted syncthing without finishing the first scan. Maybe a recheck of DB (what STRECHECKDBEVERY should do) after a scan which had had restarts or changes in exclusions could avoid this.

This is not a big issue (you can just rescan), but hard to find because the problem is only visible in the receive only devices, not in the send only, which is indeed the one failing.

For the path names, are they all in sub dir’s or spread out all over the place? You could split the job into several “smaller” ones (if you have to) will alleviate the problem of it taking too long. Just make sure your target is set to be one level down also. Then just schedule them as separate batch files and you’ll definitely cut the time down. , however, if they’re all over the place, creating 100+ separate jobs would be counterproductive. If they are within the same tree structure, create a batch that starts further down into the subdir, then you can exclude that in the batch file that copies the rest of the structure, this is the normal way. the other way is to use any of the other softwars that can handle long path names like gs richcopy 360 or securecopy or any other.

I can confirm a strange behavior of “local changes”. This times it’s not the case with overly long paths or filename, but with local changes done (rights setting accordingly). the scenario:

  • Windows 10 (1909) NTFS to read only from
  • Linux (Debian/ARM based) Ext4 to sync to only
  • Syncthing V1.4.2 (but the problem persist since quite some time)
  • rsync-based Backup on the sync folder (that’s the main reason for the rights changes)

I click on “reset local changes” in any of the folders marked as “local additions”, the folder is being scanned again, but no change in state is being performed. I understand that there are local changes, as I changed the rights (for reason I stated above). I also understand that Windows rights != Linux rights. But there should either be no local changes being detected in this case (for the file content did not change) or at least they should go away when I click “reset local changes”. Or must I activate the “Ignore rights” option? I did not do so yet, because only FAT is listed as a case, but not NTFS, which I’m using on the Windows side.

Yes you should. As you say, permissions aren’t compatible so there’s no point trying to sync them.

We should make it clear that this setting is potentially useful when syncing between different filesystems and filesystems like e.g. FAT. Main point being make FAT an example, as opposed to the current wording that implies it’s specifically intended for FAT.

1 Like

THX for clearing that up! I’ll try setting this option…

Must I resync each affected folder after setting the “ignore rights” option? I’m asking because the “local additions” state won’t go away, even when I again click on “reset local changes”!

Any logs produced when you hit the revert button? If not, please enable model debug facility and try again. Anything special about the files that are reported as locally changed? The output of for one of the locally changed files might also shed some light (instructions on linux on and for windows on [ How To ] call the REST API from Windows PowerShell.