Perhaps a basic question here but I couldn’t find an answer on other posts, and first time posting here.
A lot of directories have been deleted along with the files within them on a computer that had sync in pause. We’re talking several 10000’s files. Upon restarting to sync with other computers, I get : 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
Is there a way I can let those directories now be deleted locally?
What the error says, is that the directory contains valid files, and Syncthing won’t delete those files on it’s own. Thus it can’t delete the directory itself. You either need to delete the files in those directories manually, or you need to add them to your ignore patterns with a (?d) prefix to allow Syncthing to delete them.
@AudriusButkevicius@calmh Shouldn’t we just resurrect that directory? I mean if it was deleted on a remote because it is empty there due to ignores, but there’s valid (not ignored) files inside the directory locally, re-creating the directory leads to a more consistent end result. We already do that the other way around: If locally the directory was deleted, and we pull a valid file inside that directory, we recreate it.
True. Neither solution is particularly good. As it is now, it isn’t only causing confusion, there’s also no simple way forward to keep the directory. You have to touch every affected directory to get it rescanned. However in most situations differing ignore patterns will be the culprit, in which case fixing that is the way forward. So yeah, I guess keep it as is and explain it in a support request every now and then
i’m getting the same thing, however i’m leaning slightly towards a bug.
On the send only end, one of the St folders has “(?d) rentals.pst” in the ignore. Nothing else. However the folders which are saying they can’t be deleted locally (RO end) do not contain this file, nor anything close to this file.
The PST is buried in a totally unrelated windows folder, but St seems to be globally deciding that all windows folders can’t be deleted because there is an ‘ignore’ in place regardless of whether or not the ignored file is in there.
There’s also a discrepancy in the RO ends local state. Apparently the receiving end is showing 829 more files yet the SO end says it’s all fine. Don’t know if the mismatch is related.
I guess it’s just a typo here on the foru, but that space looks spurious.
What’s the error you get? The one in the OP 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 is about not having ignores, not about having “wrong” ignores.
If you did get the same error: Did you check in the filesystem what it is that exists within those directories?
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
essentially the SO end’s directory have been removed (probably renamed looking at the file name), however on the RO end they still exist, for example…
SO
RO
The others are also the same, directories no longer existing on the SO end are not being deleted on the RO end
Looking at some of the other directories that are not syncing, they were either renamed (as above) or moved to another sub directory. Therefore I wonder if St knows the file / directory does exist in the database but rather than updating the receive only structure to reflect the changes, it stops with the error
edit - I done a couple of tests, both in folders with and without ignores and St is working as expected. so not really sure why it’s refusing to update the local directories. I wonder if I need to force a reindex?
My question is: Is there anything in that directory on RO, i.e. if you open “3 Oak Court\Originals” or “2008” what is in there? Syncthing believes there’s still stuff in there and thus refuses to remove those directories.
Yes, the query RO end directories all have the original files.
I would expect them to mirror what’s happened at the SO end, renames / moves etc. But in my test, the moves and renames worked, I don’t understand why random directories should fail to update.
I wonder if the error is ambiguous as
directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally
isn’t exactly whats happened. The directory on the remote device no longer exists, therefore ‘is’ empty
The error is about the local situation, the situation in your RO folder. It doesn’t matter if it’s empty on the remote/SO.
Are the files that are contained there-in ignored on SO? Folder types don’t matter if the file is ignored: RO can’t mirror SO when it comes to stuff that SO has ignored (not deleted). Or differently put a folder only deletes items when it is commanded to, and your remote ignores those items, which means it doesn’t command anything regarding those items.
Example:
A and B have foo/bar. Then A ignores bar and renames foo to notfoo. Thus A tells B to delete foo, create notfoo and notfoo/bar and that it doesn’t care about foo/bar anymore. B reacts by attempting to remove foo, noticing there’s foo/bar that exists and is supposed to exist (noone ever told B to remove it), thus it tells the user that it can’t delete foo and needs help to know what is the correct way forward (delete foo/bar or recreate foo).
The error is about the local situation, the situation in your RO folder. It doesn’t matter if it’s empty on the remote/SO.
ok, I misread that, it makes sense now
Are the files that are contained there-in ignored on SO? Folder types don’t matter if the file is ignored: RO can’t mirror SO when it comes to stuff that SO has ignored ( not deleted). Or differently put a folder only deletes items when it is commanded to, and your remote ignores those items, which means it doesn’t command anything regarding those items.
no, the only ignore that’s in place on the folder was to stop one pst file being synced to me constantly as it’s a live outlook archive. The files that are in question comprise mainly of jpgs and docs
I only added the (?d) recently based on your earlier reply to the OP. It didn’t make a difference.
Just to be sure: You don’t have any ignores except that one on both RO and SO, and there’s no rental.pst in any of the directories mentioned in the errors?
Do the ignores on SO match any of the files present in the directories that create an error on RO? Or somewhat equivalently: If you add the same ignore patterns on RO as on SO, does the problem go away?
I misinterpreted this as meaning "there’s more than just (?d)rentals.pst in SO’s patterns. Then it’s unclear what is going on here.
Could you grab the output of GET /rest/db/file — Syncthing documentation (or even better /rest/debug/file which works the same but has more info) for any of the files inside the directories that cause the errors please.
I struggle (and panic) at the sight of rests and API as im on Windows, however we had a similar thread back in Feb 18 which I referred back to. Anyway, the output keeps failing…
I took a random filename from one of the affected directories on the RO side and got this
I’m sure that I have everything right, file paths etc, and based on your Feb 18 comment (I had the same PS error that time too)
The command itself is actually fine, it just responded that there is no such file (“No such object in the index”). Is the file actually in the folder root? If it’s in a sub-directory, you need to give the path relative to the root (e.g. file=foo/00b7974a-0000-0000-0000-00093d000000.vhdx ).
I wonder if it’s not in the db and hence can’t be processed / synced. Perhaps it’s easier to reindex and see what happens?
