Are there any plans to sync extended attributes in the future? The lack of this means it really can’t be used on OS X effectively.
This details what is synced and not, although you may already know that. I’m not aware of any plans to sync extended attributes currently.
(I manage to use it fine on OS X anyway, but I’m guessing you may be using Spotlight tags and stuff that I don’t.)
Is there a formal way to submit it as a feature request?
Finder icons, PostScript fonts, URL of downloaded files, aliases, old Type/Creator codes, text encoding values for text files, Tags, quarantine status, yada yada yada… 
you can always do that on github:
I can’t do it here? I hate signing up accounts to all sorts of places.
There is no good way of tracking feature requests in a forum. The Github issues website is making sure it will not be forgotten.
If you sign up there, you can also contribute with a pull request to support your or other features. 
1 Like
If you’d have created a GitHub account first, you could have used it to log in to here, to be fair 
2 Likes
Hi Jacob,
Very sorry to hear that it’s not even planned. Have installed and used Syncthing and wanted to keep it, but losing all the extended attributes of synced files is exactly why I had to abandon SyncThing. It’s basic feature of OS X, so I’m curious what the rationale behind not adding this is.
Also I think you should add a clear warning in the admin interface, that it doesn’t support Extended Attributes. As a sync tool I personally expected it to sync files in their entirety. If one trusted SyncThing to sync their stuff and then suddenly discovered that all extended attributes were lost, it could lead to lots of lost data and broken projects.
Just my 5 cents.
It explicitly says that in the docs, perhaps even the getting started guide.
Also, the basic feature which would require a fair share of effort would be useless to potentially more than 90% of the current userbase.
Regardless, I am sure we would accept a well structred pull request given someone is interested into bringing this to the table.
1 Like
I personally didn’t notice it when I tried it out or read it in the getting started docs. But I probably read it well enough. But I assume few people read the complete manual, when it’s not necesary for the setup (in an ideal world they would of course).
As I see it, the fact is that when people use SyncThing to sync items to a folder, and then rely on the synced items (maybe even at some time delete the original), they might risk losing data they need because of this. That’s why I have to keep using BitTorrent Sync, even though I would rather use SyncThing if those extended attributes were supported.
I don’t know where the 90% number comes from, and how you know that 90% would consider it useless to preserve their files as they are. Also considering the fact that many users of SyncThing are probably advanced users. But I don’t want to argue with that, just sharing my thoughts and suggestions. If you can’t use it, that’s okay. Enjoy your Tuesday.
90% of user base is non-darwin
Also, don’t get me wrong, I am not saying its a bad feature. I’d like it to happen, but someone has to put in the effort. It would be a fair share of work, as it would require protocol changes, changes how we build syncthing to link against osx frameworks making it potentially impossible to crosscompile, and so on.
Aaah ok, that makes sense. Anyway, still crossing my fingers that it will still come some time, so that I can switch from BitTorrent Sync.
We’d also need to represent the attributes somehow on non-Mac systems, and Mac systems with non-HFS disks for that matter. .AppleDouble dirs anyone? I doubt the world would thank us.
Apparently btsync stashes the data in it’s .sync dir when there isn’t a native solution, so perhaps that’s a valid alternative. Makes some things trickier as we then store data for what is essentially a single entity in multiple places, but…
It seems that you don’t need to link against anything to support them:
Cool. Go for it (in general, not you specifically ;))!
(It’s not something I myself am interested in, but a clear, useful and well tested pull request is never rejected.)
I thankfully don’t own any apples, nor do I use them anywhere else.
You could do something very stupid such as saving all xattrs for each file in .stxattrs as separate files on scan (or one large file if you wish), sync them part of the normal process, and apply them upon finishing syncing a file from the .stxattrs directory getting around protocol changes.
1 Like
That could work. I was also thinking about some protocol mechanism to tag files with whatever random metadata and just allowing a plugin to handle such things. No details beyond that figured out, at all.
The problem as far as I understand is that these things can have arbitrary amounts of data in them, potentially bloating index exchanges once again?
Options/Flags for files?
Yeah, it can’t go in the index. As you say, you can potentially stuff a gigabyte or more in an “alternate stream” or whatever.
I use syncthing to sync form Mac OS to Linux. Because extended attributes get lost I made my Mac “Folder Master” with the hope that some day extended attributes will make it to the other side for changes to go in any direction. Of-course Linux supports xattr as well, so the reverse problem may apply in other cases. So far this is not a critical issue for me, though I use tags a lot. This helps me keep a flatter, more manageable directory structure.
Because I use color tags a lot, I’m hoping that an eventual solution will allow to blacklist (or else whitelist) certain tags for a partial tags sync. That however is not as important as preserving the tags to begin with.
Keeping metadata as part of the filesystem is imo superior to non-standard solutions. So I’m considering something silly like implementing this filesharing idea with extended attributes. An alternative would be to use cozy cloud or something. With cozy though the files are in couchdb which is less convenient than straight fs.
2 Likes