Files matching (?d) rule aren't deleted


I didn’t want to make a new topic, maybe it is related – currently I have the problem that I can’t get several folders / objects in sync anymore because folders can’t be deleted – in which .DS_Store files are. I have (?d).DS_Store in the .stignore file. Should I batchremove all those .DS_Store files on the receive folders side?

Thanks and best regards, Matthias

You could have made a new topic - the original request was solved by the (?d) pattern while it doesn’t seem to work for you.

These files should be removed automatically, so you can but shouldn’t have to batch remove them. To be able to help you please provide information about your folder setup (screenshots are a good option) and actual errors and .stignore contents.

Thanks for making a new topic!

A shared folder is set on one side to send only, and on the other side to receive only. On the send only side there is a ignore pattern with the first entry (?d).DS_Store, and 3 folder names below this entry – the .stignore file is in the root path of the folder, and visible in the GUI edit folder settings. On the receive side there is no ignore pattern.

In the logs:

2019-01-16 13:20:34 Puller (folder "pool-data" (xxxxx-xxxxx), file "foldername"): delete dir: directory is not empty

In the GUI:

Out of Sync Items 2458 items, ~182 MiB / Failed Items 2.368 items

In these failed items directories are .DS_Store files. On the receive side there’s always the red ‘Revert Local Changes’ button, and I tried to rescan the folder, now it’s greyed out.

Maybe it is simple to solve! Like restarting, creating new .stignore file, etc.

I suspect this might be a problem that was already solved, but the fix only works on send-receive folders (weird interactions between deleted parent and ignored children). I remember a comment in the code and there probably is an issue too, but I couldn’t find either right now, so leaving this as a reminder. I intend to look into it at some point (and hopefully wont forget about it).

My intention was to switch now to send/receive on both sides, so maybe it is fixed then? I just wanted to be in sync first – with not many problematic folders, out-of-sync items etc.

You can also just switch over one (e.g. the receive only to send receive). Please let us know what you do and what happens.

I switched the receive only server to send & receive – now it is scanning, red revert local changes button gone, let’s see :blush:

2019-01-17 08:36:13 Puller (folder "pool-data" (is-it-save-to-post-this-id), file "folder/folder"): delete dir: directory is not empty

It didn’t change so far – I’ve deleted now the (?d).DS_Store entry of the ignore pattern, saved the change, and added it again and saved. There were now about 20.000 of .DS_Store files are out of sync, I just wanted to see if something changes at all.

Actually now that I have found the comment I was talking about, I think this is something different. Everything is working as expected, but the way it’s intended to work isn’t ideal. The following should reproduce the “problem”:

  1. Devices A and B have the same file at foo/bar, device A has ignore pattern bar.
  2. On A foo is deleted -> Syncthing marks foo as deleted and sends that info to B - it doesn’t do anything about foo/bar, as it’s ignored.
  3. B tries to get in sync, thus tries to delete foo but correctly realizes that there is still foo/bar.

Result: Pull error Puller (folder "label" (id), file "foo/bar"): delete dir: directory is not empty.

Firstly the error could mention that this is likely due to different ignore patterns between devices. However even if this is clear to the user, there are two ways forward:

  1. The file should also be ignored and deleted on B -> add (?d)bar to ignore patterns - problem solved.

  2. The file should actually be kept -> you need to touch foo/bar for it to be updated - that’s not user friendly.

Alternatives for 2 (none of them seem practical to me):

  • Automatically recreate the parent directory. Seems weird because from the point of view of A, that means it deletes a directory and Syncthing just silently recreates it without anything in it.
  • Ditch directories aka consider them just as a means to store file in, don’t actively sync them - that’s overkill for such a fringe case.

The only realistic idea I have is to add a link to the error message pointing to a FAQ question in the docs explaining the issue.

@calmh @AudriusButkevicius

(Full disclosure: didn’t follow the discussion up to this point)

So the machine that spits out the error does not have the (?d) pattern? Then I think it’s legitimate to not expect the actions that (?d) would take, to say the least…

The problem then is suboptimal things happen when files are first synced and then added to ignore patterns, as they are effectively orphaned from that point onwards.

I think this thing warrants a documentation note somewhere, and not code changes.

I also think I’ve been bitten by this same or similar thing, with the solution being to unignore the stuff I didn’t want, delete them all, then ignore them again against the future.

@imsodin Thanks for the explanation!

@calmh Yes, the machine that spits out the error didn’t had the pattern.

I did first two things: add the ignore of the .DS_Store file on B > which helped, and only 13 files out of sync, and also enable send / receive on A and B.

But @calmh s explanation seems to be reasonable, since I added the ignore pattern sometimes later (only on A, when A was send, B receive).

So the third action was right now to get rid of the ignore pattern on A and B, to get them both in sync (it is 10:00 PM and enough time until tomorrow morning :blush:).

On the other hand on another folder, which is much bigger (12,4 TB / 5.980.099 files) than the problematic one, where I never started to play with ignore patterns, there are no problems so far and always in sync.

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