How Best To Efficiently Change The Name Of A Large Subfolder

Support
1

Hello:

I’m trying to work out the most efficient way to change the name of a large subfolder which is shared between a number of nodes.

Trying this on a reasonably small folder shared between a Synology and a Mac, if I change the name on the Synology, I see on the Mac:

  • Syncthing first adds a copy of the folder with the new name, and then makes a copy of all the contained files into the new folder;
  • Then it moves the original folder into the .stversions folder.

I’m looking for a way to avoid these and instead have the change happen almost instantaneously (rather than waiting for hundreds of GB to be locally duplicated at each node), and without making an additional copy of the data (which would likely overflow the disk it resides on).

Is it safe to simply manually change the name of the folder at the same time at each affected node? Or do I need to put extra provisions in place - such as pausing all nodes, changing the name, then resuming all nodes?

Many thanks!

2

I would definitely pause all affected devices first, then rename the folder everywhere, let it be rescanned, and only then resume the connections.

Of course, I would still have a proper backup elsewhere just in case something goes wrong.

3

Thanks Tomasz - appreciate your input!

4

I think the intention is that this just works reliably out of the box. Is that not the case?

5

Hi Jakob:

It’s not that it’s not reliable - it’s just that it’s a large folder which is being heavily worked on, and the users can’t afford the downtime whilst it makes new copies of the files, into disk space that they don’t have available! :wink:

6

Well, what I’m saying is that as far as I understand it, a rename or move of a directory should reliably result in renames on the other side as well. As long as it’s within the same Syncthing folder. (The naming here is confusing, as always.)

7

We do delay deletions in the filesystem watcher. So it’s entirely possible that pulling starts before all deletion indexes have been sent. We do that to prevent a deletion event slipping in before the corresponding create event, which then would require a full retransfer. While new files first just means a local copy then delete.

However I am now wondering whether that is a valid concern at all: We delay any event by 10s. So the delete and create events of a rename would have to be at least 5s apart for them to be in different scans. That doesn’t seem very likely.
On the other hand not delaying deletes would increase the chances of direct renames a lot (especially since there’s a rename detection during scanning).

8

Even better, we do rename detection on scan, sending the new file and the delete of the old together. A folder rename should be one large scan pass over the new folder, with rename detection kicking in for each file in the tree. I hope.

1 Like
9

Ah right. I was thinking that in a rename from a/b to a/c, a/c would be first scanned without detecting the deletions in a/b, as those scan is over a/c only. However the rename detection is works “globally”, so that really shouldn’t be an issue.

10

This doesn’t seem to work for me, for some reason…

For example, I have renamed a folder with 200,000 files recently. It resulted in the folder being versioned and redownloaded on the two other devices (which took a long time, because the External Versioning is rather slow with a large number of files).

All this happened within the same Syncthing folder, with the default file watcher delay, etc.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.