Renaming files and folders

That’s possible to script using our API:

https://docs.syncthing.net/rest/db-scan-post.html

It will rescan full subdirectories as well.

2 Likes

Oh, fantastic, thanks!

Works like a charm, thanks again!

Strangely, I needed to give the folder ID, just using “default” produced a “no such folder” error, even as the default folder is the same as my sole folder.

Going to rename stuff :smiley:

1 Like

Sadly, this trick does not always work!

I did rename one season of files, used the trick with the TMP folder to rename and move in 2 stages, resyncing in between, and it worked!

But with the next season, it did not work:

I renamed into the TMP folder, resynced and all seemed fine. Then I move the files out of this folder and resented again. But here, about 8 GB of files were should out of sync and started to upload!

Strangely, the list of out-of-sync items contained the TMP folder, so somehow it tried to sync those? Even if the files were already moved out of this folder again.

That is somewhat irritating.

Maybe the remote site was not yet finished with renaming, even as “Up to date” was shown?!?

I find syncthing does not always do a rename. I have found usually syncthing will “copy from another location” and then delete the original.

If you’re using some kind of versioning you can tell because the original is moved to the trash. So you have one copy in the trash with the old name and another copy where it should be. If the copy happens first, then no data transfer has to happen. But occasionally the delete happens first and then there is. Nothing to copy from so the download happens.

Anyway these scripts are all band-aids. But none of them really address the problem that the renames are really not handled correctly.

I think within a folder, assuming no name collisions, renames should work. Across folders, this was never guaranteed, and works by chance of which folder sends updates first.

If they do not, someone should write down a step by step guide how to reproduce that (down to the level of detail of ‘create 7 files named this and that with that content’).

Saying that it happens for “you and your files” doesn’t help us reproduce the issue to understand why it happens.

I was also bothered by the need to re-download jellyfin after it was renamed. So I have an idea (not yet tested) : turn on “ignore delete” setting for the receiving device before renaming, and then turn off “ignore delete” setting when synchronization is complete. I think this can make a local copy on the receiving device, and only need to take up some capacity in synchronization to reduce network transmission.

It seems, things get worse not better with Syncthing 2:

  • Rolling hash detection of moving data is no longer supported as this effectively never helped. Instead, scanning and syncing is faster and more efficient without it.

The current version of renaming DID help, even if it has it’s problem. But no renaming anymore?

SURE???

That would render Synthing nearly unusable for me. I constantly need to rename things and sure cannot re-upload!

Really, we need multiple threads of the same bullshit? This has nothing to do with that.

1 Like

Why the tone?

Hash detection of moving data sounded EXACTLY like renamed files and folders.

If that is not meant, the upcoming change could use a better wording to be clear what it means!

It is VERY easy to misunderstand right now …

I think the annoyance comes from posting the same thing in multiple threads at the same time, which adds nothing to do the discussion but creating useless pings to people.

The weak hash is/was a feature to detect “slightly” changed files, where data was inserted (or removed) “in the middle” of the file. Syncthing then detects that all the file blocks after the inserted data are just shifted from original, and doesn’t have to re-transmit them.

While this sounds like a good idea in theory, real usage data collected by the project for many years has shown that this feature saves less than 2% of data transfer. Thus the decision was made to remove it (as there is a cost associated with this, both maintenance and performance).

The changelog could be reworded to use “shifted” instead of “moving”. Again, it deals with files where data was inserted/removed in specific ways, not about copying or renaming files to some other place.

4 Likes