delete file : file modified but not rescanned; will try again later

Support
1

Hi there It’s me (again)!

I have a bunch of Windows and Linux personal computers working together with Syncthing (family, friends, mines, laptops or fixed…) without any problem today (apart from one of them).

A little one of those computers, a Linux one (mine) encounter a problem when receiving deletes or renames from others computers : it is able to receive new files, modify/update existing files, but unable to delete them when it’s time to do so.

Also, after a rename from another computer, new file with the new name is received and appears, but the old one with the old name remains available on the disk, with one more line into “failed items”, with always the same message :

delete file : file modified but not rescanned; will try again later

error-1
error-1576×670 22.6 KB
error-2
error-2822×375 17.9 KB

The problem appears at each time : it can be reproduced at any time with any file (you move or you delete it from another computer) : absolutely no delete or rename from another computer is applied fine on this computer.

I already tried to reset the database (/home/user/.config/syncthing/index-v0.14.0.db) but the problem is back as soon as a new file is deleted or renamed from the outside.

I tried to put the folder into “receive only mode” but the problem is still there.

In the other hand, updating an existing file without deleting it or changing it’s name is fine (the new version of the file is received and applied without problem).

Do you have an idea of what’s causing this trouble ? Is my computer different ? :smile:

Also, the folder is localized on a separated hard disk from the operating system. I’ve checked anything (reallocated sectors, full disk read etc), it’s fine. But one particularity : it’s using exFAT file system, in order to be available from several Operating Systems. I’m using it for years now but this problem with Syncthing is pretty new (few weeks ago). Is it related ?

Thank you in advance !

2

At a guess, caused by the usual case sensitive rename thing - gruik to Gruik or something like that. Rename to something entirely different, let that sync, rename back.

3

Hi, thank you for your answer Unfortunately, even with complete changes of names, or simply deletes, the problem persists

At each time a given file or given name should disappear, it fails

4

You have not specified which version of syncthing you are using, but I suspect it’s because you have ignore permissions set. It’s fixed in latest RC.

5

Hi, it’s 0.14.52

I tried to disable the “ignore permission set” option, in order to do the test, as it seemed like pretty simple situation.

1
1568×514 20.1 KB

2
2874×208 10.5 KB

It seems that disabling “ignore permission set” on a “receive only” mode in an “exfat” filesystem gives a pretty catastrophic behaviour : there was >3500 files pretending to be out of sync (because of different permissions), and I had the red “Revert Local Changes” button waiting for me to click on it.

So I clicked, but it duplicated and downloaded again more than 3500 files into .stversions and at the end, was still asking for “Revert Local Changes” with always 3500+ failed items saying “operation not permited” (about chmod, that does not works on exfat) and by the way, pretending to be still out of sync.

And some thousands of tmp files are now occupying some of my folders : 5

I guess I won’t click a second time on that button :stuck_out_tongue:

I also guess that if I disable “receive only” mode, 777 permission (exfat) will be used for those files, on my other Linux computer using ext4… but I prefer it to be ignored.

So I re-enabled the “ignore permission set” and guess I’ll just wait for the next version, and do some cleaning into the .stversions folder tonight :wink:

But now, the “Revert Local Changes” doesn’t want to disappear even if I click on it.

3

Others computers are saying, about this remote computer, that some folder (containing 5 small files) are out of sync… but it’s not (and wasn’t few hours ago)… so I guess I need to reset the database again.

4

I’ll manage to get my situation back to (almost) normal here, and keep you informed of what it gives when the new 0.14.53 version will be released through automatic upgrades !

Thanks anyway for the information about this being fixed in the latest RC. And by experience : disable ignoring permission set into exfat filesystem on a “receive only” folder doesn’t work very well at all :face_with_head_bandage:

6

I had that problem too today and experienced it using syncthing 14.52 on Android. Just a note, will wait for 14.53.

7

So it doesn’t get drowned:

As all reports are for v0.14.52 and errors about modified but not rescanned in conjunction with permissions, I second that suspicion. If you don’t want to use the RC, v0.14.53 will be released soon.

8

Thanks to all of you for your advises

In order to keep a simple management of automatic upgrades trough “apt” and “unattended-upgrades” system I’ll just wait and keep the “ignore permission” function, so that the problem can disappear from itself in the following days with the upgrade.

I’ll keep you informed if something goes wrong or interesting - if not it means that everything turned fine !

Bye

9

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