How does the sync of read-only file attribute works?

[zertrin]

Hi everyone,

been using Syncthing for years (at least since 2015) but I’ve recently stumbled upon something I don’t quite understand: what should be happening with respect to the syncing when the read-only file attribute of an existing file is set/unset to/from read-only (without changing the file content)? (more precise cases and questions below).

Starting from the documentation I found the following things:

(from FAQ — Syncthing documentation)

The following may be synchronized or not, depending:

• File Permissions (When supported by file system. On Windows, only the read only bit is synchronized.)

(from Understanding Synchronization — Syncthing documentation)

During a rescan the existing files are checked for changes to their modification time, size or permission bits. The file is “rehashed” if a change is detected based on those attributes, that is a new block list is calculated for the file. […]

Changes that were detected and hashed are transmitted to the other devices after each rescan.

Moreover, a folder can have the ignorePerm option set through the GUI with the Ignore Permissions checkbox:

File permission bits are ignored when looking for changes. Use on FAT file systems.

So far, and according to my understanding of the documentation, the following reasoning should hold:

• Node setup: 3 nodes, two of those on Linux, one on Windows. Let’s name them A, B and C, with C the Windows node.
• A synced folder, where the ignorePerm option was initially set on node C, when most of the files where created, but unset afterwards.
• A file inside that folder which was not read-only on any device at the beginning (On C, the read-only file attribute is not set, on linux, the permissions are -rw-r--r-- or 644 in octal).
  • Case AA: the file was created before the ignorePerm option was unset on node C
  • Case BB: the file was created after the ignorePerm option was unset on node C
• Then without changing the content of the file:
  • Variant 1: I set the file read-only on Windows (on node C, check the read-only checkbox of the file properties dialog)
  • Variant 2: I set the file read-only in Linux (on node A, set the permissions to -r--r--r-- or 444 in octal)
• expected result: file get set read-only on the other nodes (444 on Linux nodes, read-only attribute on other nodes) in all cases.

Actual result: After waiting long enough for scanning to happen, and manually triggering the scan, the read-only file attribute does not propagate on any node for case AA (variants 1 and 2). Some testing for case BB (variants 1 and 2) shows that it works however…

So I’m confused as to why this does not work in case AA.

Are there some limitations regarding the syncing of the read-only file attribute/permission which are not documented?

[calmh (Jakob Borg)]

I think it should propagate as you assume. If it doesn’t, it’s a bug.

It works for me with a quick test on just macOS, before and after setting/unsetting ignore-permissions.

[calmh (Jakob Borg)]

Oh, OK, I can reproduce that. For files created with ignorePerms set, changing the permissions will not be picked up even after unsetting it. (Updating anything else about the file does pick up the changed permissions as well.) There is a reason for this behavior, and I’m not 100% sure if it’s a bug or not. Here’s the situation from Syncthing’s point of view after you’ve unset ignorePerms and it does the scan:

• According to the index, the globally latest version of the file is 42 and it has the no permissions flag - that is, it was last changed on a device with ignorePerms set, so we should ignore the permission bits.
• According to the index, the version we have on disk is 42, and it has the no permissions flag - that is, we are up to date.
• On disk, we have a file with the same modtime and size, but different permissions.

This is consistent with the fact that we received a file with the no permissions flag and synced it, the permissions ending up being whatever the system default minus umask dictates.

If we acted otherwise, we would send permission-only updates whenever we receive a file from some other device that has ignorePerms set.

[zertrin]

I see, thanks for the explanation. Hopefully this forum thread will be useful to anyone encountering the same situation in the future.

While we’re at it, I think I used the ignorePerms on the Windows node initially for a wrong reason and/or by superstition. The help message about this mode only recommends to use it on FAT systems, but does not really explain why, and there is nothing in the documentation on the topic. So the question which remains to be clarified is:

Why and when should I activate the ignorePerms option?

The answer to it should somehow be in the doc (I would be glad to open a PR based on your answer if you want).

[AudriusButkevicius]

Because fat, especially variants like vfat on linux, can’t store permissions at all I think, which results in every file changing post sync (loosing permissions). It’s not as bad on windows as on windows permissions are held in syncthings database.