keep getting "directory has been deleted on a remote device but contains ignored files" for no apparent reason

Support
1

Often, when I delete folders, the root and some random subfolders wont be deleted and produce directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix). The reference to the ignored files does not make sense to me, as the folders do not match the ignore patterns. For instance:, here I deleted ~25 folders, but deletion of this seemly random subset did not propagate to the st-server on my NAS:

Deleted folders:

The following items could not be synchronized. They are retried automatically and will be synced when the error is resolved.

projects/2021_swiss_invertebrates/dubendorf_ponds directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix)

syncing: delete dir: directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix)
projects/2021_swiss_invertebrates/dubendorf_ponds/Benthos_1A_Dreis_140619 directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix)
projects/2021_swiss_invertebrates/dubendorf_ponds/Benthos_3D_Macro_140619 directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix)
projects/2021_swiss_invertebrates/dubendorf_ponds/October_2019 directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix)
projects/2021_swiss_invertebrates/dubendorf_ponds/October_2019/Benthos_1B_Contr_28.10.19 directory has been deleted on a remote device but contains ignored files (see ignore documentation for (?d) prefix)

And this is my ignore pattern (via #include stglobalignore):

#recycle
.git
.local
.tox
.DS_Store
.SynologyWorkingDirectory
~$*
@eaDir
git-repos
desktop.ini

What is going on here?

2

It’s the content inside those directories that matches the patterns.

3

well that’s the thing: the directories are empty

4

Are you sure? Those are hidden files, so you might have missed them. Syncthing only throws this error when scanning the directory to be deleted and finding a file.

5

Which NAS you use? Maybe is related to NAS specific files or similar. Seems Synology. Doe you have some screenshots from the GUI or other settings?

6

I’m pretty sure the folders were empty, but I can’t tell anymore because I deleted them on the server to resolve the issue.

yeah it’s Synology DS920+. I will post here again once this issue comes up, and supply some screenshots / logs.

7

I had similar problems with elements that originally came from other platforms (Windows) on my Synology servers and also such directories could not be completely deleted via Syncthing. Therefore, I have included such elements in folder Ignorelist:

(?d)(?i)Thumbs.db
(?d)(?i).thumbnails
(?d)(?i)ehthumbs.db
(?d)(?i)desktop.ini
(?d)sync.ffs_db
(?d)sync.ffs_lock

Until now such issues are solved.

1 Like
8

Have you verified that using something like ls -lah in the terminal?

Because I don’t trust file managers provided by these funky NAS platforms. They choose to create crazy @ea et al directories, and then pretend they don’t exist by hiding them in the file manager, when they clearly do exist.

9

It is true that the @eaDir are a veritable plague in the Synology´s filesystem. If you access a Synology with the terminal under root, there are some directories in the root directory that begin with @.

However, these are directories that are not seen by the “normal” file system or by Syncthing. These are not individual files and are out of the question here. In the file system, these @eaDir directories are usually located in each root directory of the shared folder if its structure contains images, but usually not in the substructures.

Finally it is a good idea to use the terminal to check what is in the relevant directories.

10

I’m traveling at the moment, but I will check next time it happens - thanks @Andy and @AudriusButkevicius

11

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