The other way is just to rename them and then chill out. Seriously. Just wait.
If you start looking at what’s going on you’ll get in a panic and mess it up by trying to ‘fix’ it.
If you rename and walk away, Syncthing will take care of it. It just takes time while it crunches the numbers. You just need to make sure that nobody’s using the remote end while this happens.
This is real issue though, e.g. if you only have 100GB of mobile data left and you’ve renamed a 300GB folder, which now has to transfer all its contents again, or if you’re using a very slow connection, where transferring 300GB can take days 
. In other words, it’s understandable that many people would like Syncthing to handle these kind of renames better.
I needed to test this today.
I had 3 pairs of files that needed to be renamed as their names were switched.
My local site does not rescan automatically and is send-only, and the remote site is receive-only.
So I renamed them locally, then started a rescan - and bamm, Syncthing was uploading about 12 GB …
I still have no idea now to rename files and folder without triggering a new sync, uploading again.
This is horrific!
How did you confirm that the 3 sets of files were actually re-uploaded?
I’ve renamed individual files many times with Syncthing exchanging a minimal amount of data…
As a test, I renamed a 544MB file. With Syncthing’s default 10-second countdown timer, it took 11 seconds for the sync to finish.
Transferring 544MB in 1 second requires 4.5Gbps, but I’ve got a 1 GbE network switch and bandwidth throttling on each server capped at 200 Mbps, so only Syncthing detecting and acting on the rename makes it possible.
Metadata from server “A”:
$ stat rescue.iso
File: rescue.iso
Size: 556588867 Blocks: 1081088 IO Block: 4096 regular file
Device: 0,38 Inode: 550 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 9001/ gateway) Gid: ( 9000/ gateway)
Access: 2023-09-22 13:56:20.603839793 -0500
Modify: 2023-11-20 11:53:17.913189956 -0600
Change: 2025-03-21 11:49:18.512671977 -0500
Birth: 2023-10-09 20:37:12.576666665 -0500
Metadata from server “B” after the file rename had synced:
stat rescue.iso
File: rescue.iso
Size: 556588867 Blocks: 1081088 IO Block: 4096 regular file
Device: 0,44 Inode: 20773 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 8384/syncthing) Gid: ( 8384/syncthing)
Context: unconfined_u:object_r:samba_share_t:s0
Access: 2023-11-20 11:53:17.913189956 -0600
Modify: 2023-11-20 11:53:17.913189956 -0600
Change: 2025-03-21 11:49:29.412193275 -0500
Birth: 2023-12-12 10:23:56.256882244 -0600
Note the difference between the two timestamps (~11 seconds):
Change: 2025-03-21 11:49:18.512671977 -0500
Change: 2025-03-21 11:49:29.412193275 -0500
(I was also watching a network traffic monitor during the rename.)
I saw it displayed on the Syncthing website, that it is uploading and have the “Stats” utility that showed the actual upload rate - and no, nothing else was uploading!
The files each are around 2GB, so 3 pairs of files is exactly 12 GB, what was shown on the Syncthing website!
And when Synching was finished, Stats also showed that nothing get’s uploaded anymore.
Clear enough, I would say.
Maybe that works when exactly ONE file got changed?
That is not a usable way for me … also I need to rename folders too, from time to time.
Sadly, I have no shell access to the remote site and cannot rename myself.
With the download / upload rate counter reset to zero for easier reference, renaming a 544MB file required 264KB of data from a send-only device to a receive-only device:
Upload rate peaked at 4.64 Kbps (with the sync finishing in just 1 second I didn’t have enough time to grab a screenshot).
Since normally two things cannot be true at the same time, either my servers are capable of quantum teleportation (I wish 
), or there’s something unusual about yours.
Maybe I missed it, but I didn’t see a more detailed description about your setup in terms of OSes, filesystems, etc.
Thanks.
I will try to rename exactly one file and test this, reporting the results here!
But when this work, it still is not a usable way for renaming - it would take an immense amount of time to sync one by one.
As I said, Syncthing really is missing a rename-mode!
I tested and you are right!
When only one file got renamed, the change will be changed and no re-upload occurs!
I will later test with 2 files which names need to be exchanged:
“A” → “B” and “B” → “A”
This is what I mostly need to do …
I first tested “A” → “B” and “C” → “D” just to be sure, and this also worked fine!
Here we have it!
Rename a pair for files, switching their names does NOT work!
This reliably triggers a new upload!
And to explain why this is needed, in that case we talk about movies and shows for a Jellyfin server and I have bad naming of episodes - their sequence is wrong and needs to be fixed, most of the time by exchanging the names of two files … or circle rename several of them.
Yes, pretty much the same effect as renaming a folder. The pair of files are processed by Syncthing within the same batch.
Remember, for efficiency reasons there’s a default 10-second countdown timer that delays processing.
I also have the same naming issues with my video and music collection.
Given the following conditions:
Change the fsWatcherDelayS from the default 10 seconds to 0 – since you don’t usually use it, you won’t need to revert it back to the default.
Then, whenever you want to name swap, temporarily enable file watching (“Watch for Changes”) which fsWatcherDelayS is dependent on.
With fsWatcherDelayS set to 0, Syncthing will act immediately on a rename, scanning and pushing the rename across the wire. Take a breath, then continue with the rest of the steps – i.e. rename A → C, breath, rename B → A, breath, rename C → B.
The idea is to allow each stage of the “circle rename” to complete in its own Syncthing batch process.
No, I tested this!
You can rename A->B and C->D, yes!
But you cannot rename A->B and B->A, switching the names - then, both will be uploaded again!
And, for one of my shows for Jellyfin, makemkv messed up lots of names and such a renaming is required:
1-3
2-1
3-2
7-10
8-9
9-8
10-7
11-13
13-11
That will does not work with how Synthing works!
Tomorrow, I will test if this can be prevented by renaming first into a new sub-folder, resync, mv up from the sub-folder and resync again.
Maybe that is a workaround.
These kinds of workarounds are a pain. It really would be great if for specific folders we could specify that all scanning should complete before sending any changes and hashes for changed files could all be matched with existing files after the updates are sent and files or directories are moved or renamed before any transfers begin.
This could be an option disabled by default and on existing directories but could be changed if this special behavior is useful for a specific folder where large files or directories are regularly renamed.
As it is now, things can get ugly if large files or directories are renamed with many many GBs being retransmitted and many many GB of files being moved to stversions unexpectedly instead of just being renamed.
For the record, the lowest supported value is actually 0.1. However, in the past, someone reported performance issues with using such low values (see High CPU usage that does not decrease after synchronisation is complete · Issue #9135 · syncthing/syncthing · GitHub). I’ve personally tested using a value of 1 for some time, and it did work fine. I found it too aggressive though, so currently I use a value of 5.
This is very much a special case, and indeed not supported. For clarity, this is how Syncthing’s rename detection works:
On the receiving side, we look for add+delete pairs and convert to rename.
This won’t work if you switch the names of two files between each other. I expect that’s a rather unusual operation, and one that can’t even be represented on the destination as an ordered set of renames from source to destination.
It should work fine for 1 file or 1000 files though, including renaming a folder with a lot of files in it, so if it doesn’t that’s something for someone to troubleshoot.
Great many thanks!
I just found a solution for the problem (which is an incredible common problem between all people I personally know that use Syncthing - they all sync their media libraries, and here you have that problem!)
The WORKAROUND is as follow:
mkdir TMP
mv A TMP/B
mv B TMP/A
resync
mv TMP/* .
resync
Works, as far as I tested - also more many files and folders that need to be renamed.
I am currently scripting this, as I will need it hundreds of times, now and in the future.
I wanted to edit my initial posting to have the title contain “[SOLVED]” but for some strange reason, I am not allowed to edit my own posting.
That is ridiculous
BTW, I would like to see a new feature:
Rescan only a sub-folder, not the whole top-level directory.
Each of those scans takes a long time and with being able to select or enter a sub-folder, all such renaming would be MUCH easier and faster!