Open spoorun opened 7 years ago
See also #4216
As for the mentioned caveat, I wrote a paper about it for DC-2011 proposing a solution for proper xattr transport throughout filesystems. But nobody cares about xattrs. And those who do do it their own way without considering others… Maybe it'd be an occasion to do this properly.
About the limited length, Linux itself (ext2,3,4 actually) has a hard limit of one block per inode to store all its xattrs. It might seem large for people never using them, but on Haiku for example we store icons and other stuff in them. The Haiku cross build used to fail because the archiving tool had a too large attribute storing the list of supported archive mime types, so we had to work around it.
I'd like to sponsor this feature!
About the limited length, Linux itself (ext2,3,4 actually) has a hard limit of one block per inode to store all its xattrs. It might seem large for people never using them, but on Haiku for example we store icons and other stuff in them. The Haiku cross build used to fail because the archiving tool had a too large attribute storing the list of supported archive mime types, so we had to work around it.
@mmuman, does a kernel issue exist for this?
Don't think so. I remember sending a mail to Ted Tso once but never got any reply. I believe they consider this a feature, probably because this avoids having to write complicated code to account for them in disk quota…
Currently other systems (such as KDE) utilise the file extended attributes (xattr) metadata to store tag information (using user.xdg.tags).
Use extended attributes to store tags where possible.
Read and apply tags from other systems which are stored in extended attributes.
This would enable true tag portability, data resilience, and tag syncing and sharing.
Caveat: though all common and modern filesystems support extended attributes (albeit FAT, HPFS, and NTFS support limited length extended attributes).