Nested folders keep reappearing

Support
1

Hello there! New to Syncthing and already experiencing issues. I am in the middle of setting up a 3 way sync topology. 3 Linux nodes with one shared folder in send/receive to each other, in a full mesh arrangement. Everything seems to work, except one thing.

When I delete a folder which has subfolders (which in turn may have subfolders themselves), the folder gets momentarily deleted from the local node, but after a short while it comes back except the deepest directory level. For example, I execute:

mkdir -p folder/1/2/3/4/5/6/7/

rm -rf folder

After a while I get back folder/1/2/3/4/5/6/ while subfolder 7 is missing. If I issue the same ‘rm -rf folder’ command, the same cycle repeats and gives me folder/1/2/3/4/5/ with folder 6 missing, and so on.

By trial and error I have determined that this only happens when “Sync ownership” is active, while deactivating that option makes everything behave as expected. Yet, I can’t afford to turn that off, as it’s a requirement for the project I’m trying to develop.

Has anyone met the same issue already?

Snippet from the logs when deleting nested folders, after the deleted stuff has already come back:

2024-02-21 12:19:35 Puller (folder “plesk_sync” (vcuw2-rljm7), item “test/1/2/3/4/5/6”): syncing: delete dir: file modified but not rescanned; will try again later

2024-02-21 12:19:35 Puller (folder “plesk_sync” (vcuw2-rljm7), item “test/1/2/3/4/5”): syncing: delete dir: directory has been deleted on a remote device but contains changed files, scheduling scan

2024-02-21 12:19:35 Puller (folder “plesk_sync” (vcuw2-rljm7), item “test/1/2/3/4”): syncing: delete dir: directory has been deleted on a remote device but contains changed files, scheduling scan

2024-02-21 12:19:35 Puller (folder “plesk_sync” (vcuw2-rljm7), item “test/1/2/3”): syncing: delete dir: directory has been deleted on a remote device but contains changed files, scheduling scan

2024-02-21 12:19:35 Puller (folder “plesk_sync” (vcuw2-rljm7), item “test/1/2”): syncing: delete dir: directory has been deleted on a remote device but contains changed files, scheduling scan

2024-02-21 12:19:35 “plesk_sync” (vcuw2-rljm7): Failed to sync 7 items

2024-02-21 12:19:35 Folder “plesk_sync” (vcuw2-rljm7) isn’t making sync progress - retrying in 1m0s

2

This is probably the same issue as

And it’s being worked on;

It seems to be caused by directories’ mod/inode times changing when child objects get modified or deleted. When syncing extended attributes or ownerships, we seem to take these mod/inode times of directories in special consideration - but we probably should not as they don’t say a lot about the object it’s about.

3

Thanks, @er-pa, I think it’s the same issue, I have also tried repeating a few of the (many!) diagnosing steps that @luckman212 has taken, with the same outcome (i.e. renaming a directory ends up having two of them, one with the old name, one with the newer). As I understand it, it’s not strictly Mac-related but applies to other platforms as well, or at least my findings on a different system seem to confirm this, right?

Any ETA for the fix (if it’s scheduled at all) or temporary workaround?

4

@francescoca Yes, I’m desperately hoping for a fix in the Mar 6 release of 1.27.4, but no guarantees.

For now I would suggest you may want to compile a build based on my PR #9424 and test it in your environment.

5

Can’t afford that for the moment being. I will test separately and report back. In the meantime I’d like to let you know that reverting to ST 1.26.1 works fine for me. This is good enough for now as a temporary fix, so that I can progress with my project, and then upgrade once the whole thing is corrected. Feel free to ask me any test you may find useful

6

Is this coincidentally simply the previous version you ran, or did you backtrace it step-by-step to that version?

7

No, I didn’t go back step by step, I picked up a not-so-old version, but skipping the whole 1.27.x family (my first attempts were on 1.27.2, and the problem was already there). What I hope for, is that the issue will get corrected in a relatively short time and then go further to the latest release.

1 Like
8

@francescoca I worked on this yesterday and posted a revised PR: Updated solution for #9371 (ignore xattrs when performing directory deletes) by luckman212 ¡ Pull Request #9430 ¡ syncthing/syncthing ¡ GitHub

If you have Go installed you could compile and test it, would be appreciated.

9

As soon as I have some time, I will do my homeworks :slight_smile:

1 Like
10

There were some private messages exchanged between myself and @francescoca about compiling the build. Long story short here are the commands to do it in case anyone else wants to try

git clone https://github.com/luckman212/syncthing.git --branch patch2-for-9371

cd syncthing

go run build.go -no-upgrade -version 'v1.27.4-rc.2-9a83fbfa8'

Still, it hasn’t solved his issue.

When I re-read the thread, I realized in this case we’re talking about syncing ownership, not Xattrs. My patch only dealt with the edge case of deleting folders when SyncXattrs was enabled. I think we’ll need to extend the fix to also take into account SyncOwnership (ownership sync).

@er-pa do you agree?

11

@francescoca Would you mind re-cloning the repo with the latest commit, building and re-testing? I applied the fix for ownership and squashed, the new commit is 9a83fbfa8

12

In a short while, probably.

EDIT: this one is ok, works just fine for me! So good!

13

Great, thank you for that!

14

No problem, hope your patch is verified and merged ASAP.

Thank you for the great work!

15

Good news is this PR has just been merged, so it will appear in an upcoming version. Not sure if it’s going to land in the next release but should be “soon” :slight_smile:

1 Like
16

Great! Looking forward to it. Thanks again for your commitment

17

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