Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilise and store tag data in extended attributes #4217

Open
spoorun opened this issue Apr 5, 2017 · 5 comments
Open

Utilise and store tag data in extended attributes #4217

spoorun opened this issue Apr 5, 2017 · 5 comments
Labels
1. to develop Accepted and waiting to be taken care of enhancement feature: tags hotspot: filename handling Filenames - invalid, portable, blacklisting, etc.

Comments

@spoorun
Copy link

spoorun commented Apr 5, 2017

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).

@spoorun
Copy link
Author

spoorun commented Apr 5, 2017

See also #4216

@mmuman
Copy link

mmuman commented Sep 8, 2018

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.

@nextcloud-bot nextcloud-bot removed the stale Ticket or PR with no recent activity label Sep 8, 2018
@skjnldsv skjnldsv added 0. Needs triage Pending check for reproducibility or if it fits our roadmap 1. to develop Accepted and waiting to be taken care of and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Aug 20, 2020
@whiteonion
Copy link

I'd like to sponsor this feature!

@RokeJulianLockhart
Copy link

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?

@mmuman
Copy link

mmuman commented Aug 27, 2023

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…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of enhancement feature: tags hotspot: filename handling Filenames - invalid, portable, blacklisting, etc.
Projects
None yet
Development

No branches or pull requests

8 participants