Extended attributes are name/value pairs that can be assigned to any file and directory. They allow for more infomation to be embedded in the filesystem when file and directory names aren’t enough, like ID3 tags on mp3s. Most Linux distributions and filesystems support it, and you just need to turn it on. Linux.com has more.
Interesting, but not as useful without application support.
like BeOS or Zeta have then ….
The problem Linux will face will be getting everyone to agree on exactly what attributes to use and exactly how to use them. Until some basic standards have been agreed upon, extended attributes and the additional useful meta-data that comes with them will be next to useless for the majority of users. What good will it be to the user if the Vorbis file they’re playing in Xmms has all of the track information in a series of attributes if Xmms doesn’t know to read them? Or worse still, if E.g. the artist name is in an attribute called “Artist” and Xmms is looking for an attribute named “performer”?
There is an additional problem that application developers face that the attributes API exists for Linux, but not for other OS’s E.g. FreeBSD or Solaris. If you’re writing portable code (Such as KDE or Gnome), you’re not going to be able to use those API’s. Linux is likely to see some support for extended attributes, but nothing universal.
Not to be pessimistic or anything, but this is the very sort of thing that developers have been very poor with in the past.
when emailing a file, or retrieving it by ftp, of using samba (smb/cifs), or nfs – then you will lose the EA data.
maybe apple’s former file format with forks wasn’t that bad after all.
still i’m a huge supporter of EA’s. and for the problem above, maybe the filesystem layer can create (unicode) text files for each file, with an “.ea” extension and hidden by default, of something like that. or ftp servers could automagically show those .ea file information, downloadable as a text file, and easy to restore if you have both the file.normal and file.normal.ea
You make it sound like adopting this would be impossible. If done with some planning, it is quite possible especially for GUI applications because the appropriate frameworks can easily abstract this functionality. Picking the defaulst is actually the easiest part: name, size, group owner, user owner…just use the current information about the file that is available with all current filesystems.
I hope that KDE, Gnome and such plan on adding this functionality because once you start using it, you don’t want to go back. Trust me, I am an ex Be user, and I still miss that functionality shared across the system.
> API exists for Linux, but not for other OS’s E.g. FreeBSD or Solaris.
That’s wrong, BSD has POSIX xattr support (OSX Tiger has them from BSD btw)…
Slowlaris has xattr support since years, but it’s quite different (recursive: an attribute is actually a file which can also have xattrs by itself, …).
And even for Linux, the problem is even the API they can’t agree upon!
There are like 3 API for xattr in Linux.
One API has the value as (void *, size_t), another one as a char *… So are they strings forever (quite limitating) or random binary data (not very helpful unless you know the format) ???
In BeOS & ZETA they are *typed* which solves that and allows apps to handle attributes they don’t know about… and index them in the fs the way they are supposed to be (int32 are intexed as integers, not strings).
Why POSIX didn’t standardize on something that was useful, used and worked (even if not from Unix, not everything-non-unix sux) is beyond me.
In BeOS, BeMail optionally sends attributes as a 2nd attachement.
And you can always use zip.
I never said adopting extended attributes on Linux would be impossible. In fact you & I agree that it needs to be done with some form of planning behind it. Although I have to disagree with your list of default attributes; all you are simply doing is duplicating existing meta data. The big problem will be what additional information should be provided.
KDE and Gnome are unlikely to adopt extended attributes at this point though, even if they want to. How can a cross-platform desktop environment make effective use of platform specific features like these? Neither KDE or Gnome would ever tie themselves to Linux in that way. Adoption on Linux is likely to be slow because of that.
It’s given me headaches just trying to imagine a bijection to map the typed BeOS attributes to that crappy POSIX scheme for interoperability
On the funny uses of xattrs (and queries), I can’t resist to put that googlefs shot once again… Yeah I have a 8 058 044 651 entry bookmark.
http://clapcrest.free.fr/revol/beos/shot_googlefs_006.png
It uses UTF-8 of course http://clapcrest.free.fr/revol/beos/shot_googlefs_007.png
another option is to put a virtual layer on top of it, so each EA becomes a directory. like all files with author=foo will be in the directory author(foo), and when only one file has an EA like title=bar, it will show as a file with filename title(bar)
that way, all applications can benefit… but how to write that virtual layer? it doesn’t look to difficult, someone who has some experience with writing lufs filesystem drivers?
So, Linux has had kernel and filesystem support for standards-based file metadata for YEARS, and you’re telling me the distro’s haven’t even TURNED IT ON??
ANY other OS would (and have been) be bragging to high heaven about standardized integrated metadata attribute support. And how many hacks have Gnome and KDE had to put together in the past few years to achieve the same thing?
-braddock
> and you’re telling me the distro’s haven’t even TURNED IT ON??
Cause they didn’t care ?
> And how many hacks have Gnome and KDE had to put together
> in the past few years to achieve the same thing?
Good old things… relying on file extentions to know the type and all those hacky stuff.
Sure extentions can give hints, but in BeOS when it’s sniffed or if you force the mime type, it sticks, even if you remove or change the extention.
I don’t know how the situation is right now but storing file xattr away from the file location seems (and is) pretty inefficient.
http://lwn.net/Articles/112566/
It’s true agreeing on standard EA’s will be hard, sadly.
But there is at least one standard attribute already:
mime_type – name says it all.
ROX-Filer supports setting it and uses it for mime type detection.
My Contacts address book saves its files with EA’s on Linux (ext3,ReiserFS,XFS) and Solaris. Adding this to an application takes about 10 min. It would take less than an hour to add this to Gtk+/Qt fileselectors. That it has not been done yet – there are no excuses. Don’t let you be had by devs with portability nonsense, there are no portatibility issues. On unsupported filesystems setting EAs simply fails silently without harm done, just like Unix file permissions are lost when you copy your media files to a FAT formatted pendrive. And you wouldn’t think Unix permissions are useless because of this…
Shouldn’t be too hard to agree how to map EXIF or ID3 data onto EA’s at least – you simply use the names defined by the standards for these kind of things.
Does anybody know the C system calls
which are used to manipulate these attributes?
For Linux you find it in the man pages for the “attr” package.
Example:
#include <attr/attributes.h>
int attr_set (const char *path, const char *attrname,
const char *attrvalue, const int valuelength,
int flags);
int attr_setf (int fd, const char *attrname,
const char *attrvalue, const int valuelength,
int flags);
Thanks!
In what do they differs ?
I thought reiser4 metadata worked something like this.
mmu_man:
Holy [expletive deleted] that’s cool! Why have I not heard of that on any of the news sites?
filemanagement working properly first!
It’s sad but I found out the hard way when using fat partitions with Linux, it’ll trash the file attributes causing bad data loss.
Example, you have a bunch of files somewhere and copy them to fat partition. All modification dates and times are changed to current date and time. This is equivalent to data loss.
It’s a dirty little secrete of Linux that people don’t talk about!
Yes, I know about the cp -p thing but all graphical file managers don’t use that.
So use Konqueror, emelfm or most other file managers to copy files and if you rely on the file date then you’re toast.
Midnight Commander is the only file manager that has the “preserve attributes” checked by default and works ok but I’d rather use a graphical file manager.
This whole situation stinks and nobody is doing anything about it.
So never mind Extended Attributes, let’s just fix the problems at hand first!
Shouldn’t be too hard to agree how to map EXIF or ID3 data onto EA’s at least – you simply use the names defined by the standards for these kind of things.
Yes, but what would be that point of that? The EXIF or ID3 data would have to be kept for use with applications/platforms that don’t support EA, so you’d just be duplicating the data and what benefit would it provide?
> so you’d just be duplicating the data and what benefit
> would it provide?
All xattr aware apps can read xattrs (minus the infinitely stupidly mistake of not having them typed).
Only apps that handle EXIF or ID3 actually handle EXIF or ID3.
@Vanders
You say that my suggestion about the defaults is just replacing the meta data, and you are correct. That is the goal. To facilitate the slow move from a limited set of meta data about a file/directory to a full-scale “unlimited” attribute system. Move the basic meta data information initially so the system can still get the basic data, but now the user has the ability to add as wished.
KDE & Gnome apps develop to the appropriate API/classes. Giving the frameworks the ability to report the new attributes without breaking then with other systems that don’t support filesystem attributes is straight-forward not trivial. The best place to start I think is that the toolkit level first. I can only think of a few CLI apps that need to be aware of the attributes (tar, cp, mv) because the rest can just use the normal default attributes/metadata.
Just my $0.000000342256
I would like to see that in Konqueror.
It could work with the search bar (which would then not be used to search with google, but to search for files with the given attributes in the current folder).
Nice thing though
Seriously, what does extended attributes give you that a configuration file with a standard format doesn’t? That’s why nobody bothers with them.
Like the M$Windows registry it’s just another way of putting data into a ghetto where the standard file system tools can’t be used. All the file system tools have to be reinvented (e.g. grep), usually badly, and all the file system semantics have to be reengineered (e.g. serialising data and metadata through named pipes, shared file updates, file caching or file memory mapping), usually badly.
I’m all for standard configuration file formats shared by multiple applications but extended attributes unnecessarily complicate the kernel. They are more appropriately implemented in user space as regular files.
Metadata = data. Don’t be sidetracked by the different names. Treating it differently causes unnecessary headaches.
The existing file attributes are metadata because they affect file semantics in ways that must be enforced by the kernel (i.e. file protections). This is not true of the metadata name/value pairs being considered here.
http://www.beaglewiki.org“ beagle uses xattrs to store indexing information, afaik.