Serialize extended attributes ?

Mildred ml.mildred593 at
Sat Jul 14 06:07:20 PDT 2007


I would like to see the extended attributes more widely used,
especially for the mime type of documents. The libmagic is really good
but sometimes it can't really detect differences between files types
that are really close. And extended attributes can be used to store
others informations like the encoding (utf-8, iso-8859-1, utf-16, ...)
of text files.

There is already something:

It says :

> An implementation MAY also get a file's MIME type from the
> user.mime_type extended attribute. The type given here should
> normally be used in preference to any guessed type, since the user is
> able to set it explicitly. Applications MAY choose to set the type
> when saving files. Since many applications and filesystems do not
> support extended attributes, implementations MUST NOT rely on this
> method being available.

The problem is that "many applications and filesystems do not support
extended attributes".

This problem occurs also when you want to send a file to someone else
or when you want to store a document with extended attributes on a
filesystem where extended attributes are not available. So what about
creating a special file that will serialize extended attributes. So the
data found in these attributes would not be lost.

I had the idea that the extended attributes could be like mail or http
headers. That is the name of the attribute followed by a colon ':' and
the data. After all attributes there would be a blank line and the file
The extended attributes can be also serialized in a separate file that
must come with the file it refers to.

So that specification would be implemented by unix commands like cp or
filemanagers. Then it would permit us to use extended attributes
knowing that they would be preserved and reliable.

Also, what about using extended attributes to cache the guessed file
type (guessed using libmagic and extension). Then when a filemanager or
any other application want to know the file type, they will use this
value instead of using guessing another time.

I also thought that extended attributes could store the size of a
directory. For example when I want to scan the filesystem with
utilities like du or Baobab, they would store in extended attributes
the directory size along with the time when it was measured.
Afterwards, when they want to know the directory size, they could just
compare the date in the extended attribute with the modification date
of the folder and if they differs, measure the directory size. If not,
they could just use it directly.

Something else. We can imagine that files with the attribute
user.xdg.title would be displayed using this title instead of the
filename in file browser. Of course it should be configurable in the
file browser and maybe only enabled on some folders where it is
meaningful. For example i would like to be able to browse my mails
using my filemanager. The mails are stored in folders, one file per
mail and their filenames are just a sequantial number. I would like to
be able to change the view of my filemanager in those folders so I
could see the subject and sender of the mail instead of the sequential
number. But of course, the file manager should still be able to display
the filenames.

I think the extended attributes should be better integrated in the
desktop. These are just few ideas. What do you think about it ?


Mildred       <xmpp:mildred at> <>
Clef GPG :    <hkp://> ou <>
Fingerprint : 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]

More information about the xdg mailing list