Renaming large folders takes long and seems inefficient

Support
1

Hello,

I am trying out syncthing at the moment and am doing some tests.

I encountered a problem which probably has to do with this error:

error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally

The setup is as follows:

  • 1 Windows 11 PC
  • 1 TrueNAS server with Syncthing app
  • Both have a shared directory that is supposed to synchronize automatically.

In principle, this works.

However, I noticed that synchronizing directories that have been renamed takes a very long time.

What is being synchronized: 7,200 files, 804 folders, approx. 3.9 GB (1 parent folder with Wordpress within and 1 large file)

When I create the files on the PC and they are synchronized to the server, it takes approx. 3 minutes. When I rename the parent folder and the file, synchronization takes approx. 2-3 minutes.

I don’t know exactly what happens, but the process seems to be something like this:

Syncthing creates a new folder with the new name (visible on the server’s file system), then copies the files into it or over the network (probably not, as this is too fast), at which point a problem occurs, see log:

2025-12-17 11:52:34 INF Deleted directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/wp-content" dir.permissions=0755 log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev/wp-content" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Deleted directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev/wp-content/plugins/wordpress-seo" dir.permissions=0755 log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev/wp-content" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Deleted directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev/wp-content/plugins" dir.permissions=0755 log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)
2025-12-17 11:52:34 INF Deleted directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev/wp-content" dir.permissions=0755 log.pkg=model)
2025-12-17 11:52:34 WRN Failed to sync (path="Webseite Wordpress/V2 Dev" error="syncing: delete dir: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" folder.id=dataset folder.type=sendreceive log.pkg=model)
2025-12-17 11:52:34 WRN Failed to sync (path="Webseite Wordpress" error="syncing: delete dir: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" folder.id=dataset folder.type=sendreceive log.pkg=model)
2025-12-17 11:52:34 INF Folder failed to sync, will be retried (wait=2m0s folder.id=dataset folder.type=sendreceive log.pkg=model)
2025-12-17 11:54:34 INF Deleted directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress/V2 Dev" dir.permissions=0755 log.pkg=model)
2025-12-17 11:54:34 INF Deleted directory (folder.id=dataset folder.type=sendreceive dir.name="Webseite Wordpress" dir.permissions=0755 log.pkg=model)

Then a few empty folders remain and nothing happens at first, the status jumps back and forth from “Current”/green to “Not synchronized”/red, and at some point it is green and synchronized again. Then everything is OK. Times: Creating and copying folders until the problem occurs: approx. 30 seconds or faster. Strange status and problem resolution: 1.5-2 minutes.

Do you know what is going on there?

I fear with more PCs involved that could easily result in a confusing synchronization state.

Thank you,

Michael

2

There are multiple discussions about how renames don’t really rename files. Syncthing sees it as one deleted directory and another new directory added. Often the files are copied from the local directory before the directory is deleted. it does seem to be that there is a provision for renaming files but it seems that facility is often not triggered.

the net effect is a rename usually triggers a duplicated copy and then a delete.

If the delete isn’t happening because the deleted directory isn’t empty it’s probably because of ignored files. There is a way to specify that only if ignored files are present in a deleted directory they can be deleted. Check the ignore rules documentation for the flag.

3

Thank you for the reply. There is a rule for ignored folders (*.zfs), but there is definitely no such folder in this tree. In addition, the directories are deleted at some point. Only very late, and the log contains this error message. The end result is a correctly synchronized directory, but the path to get there is long and confusing.

4

For renaming, delete the folder in the GUI, rename it in file explorer, after all the renamings are done, set up folder again. If you rename while its online. A lot of problems happened because it renames but fall behind, making the new rename too fast, and the syncthing renaming fall behind. Usually None of the folders are held by each instances, as syncthing warnings.

5

Pretty sure we are talking about renaming subfolders…. Not renaming the folder.

If you want to change the folder path, shut down syncthing, rename the folder, edit the config file and start back up. But that’s not what we are talking about here.

6

It still applies. Usually fast renamings in subfolders could gone awry. WhatsApp media sub-folders renamings, Obsidian sub-folders, etc.

I usually shutdown my instances first.

7

It doesn’t help.. you’d have to shut down both instances on both sides, make the rename on both sides and then restart both instances on both sides.

If you’re doing all the renaming manually what’s the point of a synchronization program?

Renames are broken as has been discussed in multiple threads over multiple years.

yes the end result is okay, but renames of large directories almost always result in files being copied and deleted instead of renamed, take a lot longer because of all the extra disk I/O, (even if no network traffic is required to move data) and in the case of versioning result in a copy of the whole renamed folder in the versions folder.

I literally have a 9TB versions folder now with probably 4TB of “extra” copies of renamed directories that I haven’t gone through to clean out.

Renames don’t work.

8

Yeah thats true. At least the sync conflicts appear in my obsidian instance. Diffing them would make them disappear (instead of one existing). I never touched the sync conflicts. It is a problem but I kind of just five give* up on sync conflicts.

9

Sync conflicts are a different situation. There are a lot of threads about obsidian here but I don’t use it myself.

The original point here is about a rename of a large folder taking a long time.

10

I’ve logged the entire process now, maybe that helps understanding whats happening.

I’ve changed the folder “webpage WebpageX” to “webpage WebpageA” on the pc and synced it to the server.

I think this is important, but I don’t know:

2025-12-18 17:20:24 INF Failed to delete directory (folder.id=dataset folder.type=sendreceive dir.name="webpage WebpageX/V2 Dev/lm-includes/js/tinymce/plug/compat3x" dir.permissions=0755 error="directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally" log.pkg=model)

I tested the whole process with Qnap Qsync and a folder or file rename (no matter how big the whole tree is) is done in (milli-)seconds. It seems it detects a rename and tells the remote to simply do the same.

As a sidenote:

I also use a Qnap NAS with Qsync for years now and it was about 100% reliable so far. It has a nice UI and very good logging out of the box. The only downside is, that it only works with Qnap and it is slow as hell when it comes to syncing. It also consumes a lot of resources. Syncthing seems to be a real gamechanger here when it comes to sync speed and system resources. The only downside is, that the whole solution is very teccie and when it comes to logging: most of the times logs are really boring, but you never know when a problem occours and then a log is worth its weight in gold. So a proper and easy to understand log of the last X-thousand files would be a really nice thing I think.

server.txt (9.1 MB) windows.txt (313.0 KB)

11

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