Proposal: File attribute synchronization

Feature
1

Hi there,

i am aware that there is no explicit 1:1 mapping of file attributes across different filesystems. The only two atributes that are usually available on filesystems are RO and A.

But syncthing could introduce an option called “Share extended file attributes” that enables this feature:

My proposal is, syncthing could provide a virtual file for every shared file, which contains serialized file properties. e.g. a file named “test.txt” initally shared from a windows machine will share a file “test.txt.st_props” along with it. This file could be placed next to the file, or a bit more user friendly, in a parallel tree which is placed next to the “.stfolder” file in the root of the share.

Content of that “test.txt.st_props” might be smth like XML:

< NtfsAttributes> < Compressed value=“true”/> < System value=“false”/> … < /NtfsAttributes>

Every client who understands NTFS attributes, could adopt these attributes. Clients not supporting these, will apply their attributes as they are do now. Now the new client can provide a more recent version of the file by adding its new < LinuxAttributes> to the test.txt.st_props, containing uid/uname/gid/gname/mode etc

When one of the two clients is offline, it could serve the attributes to newly connected clients even if they have a different file system type. If file properties on disk change, the file will get updated and distributed into the network. Even if the client is configured to not apply attributes for some speicifc share, or if they should completely ignore file date/time and attributes (new option?) they can still deliver the attributes from the test.txt.st_props.

This would allow use to use syncthing as “live-backup/migration” tool too. :wink:

What do you think about that feature?

BR, g3gg0

2

We could, kind of, support optional attributes in the protocol and keep them in the database. I’m nut sure we gain much by also keeping them in a parallel file tree though? The tricky stuff is probably the OS specific syscalls and the resulting testing…

3

thanks for your reply.

the key component is storing the attributes for all known (or unknown) filesystem layers in some extensible container, which then can be pushed from any device, even those who do not understand the attributes.

a scenario i am trying to address with that: old linux home server --> (internet dynamic IPs) --> remote workstation to backup newly create files and changes on the server onto my workstation in background. so if anything happens, i have the latest files available, and can probably restore them.

but right, setting properties is some work though, especially with corner cases. (set UID or lookup local UID by name? etc)

BR, g3gg0