Support extended attributes

Bug #112909 reported by Johann Petrak on 2007-05-06
This bug affects 4 people
Affects Status Importance Assigned to Milestone
ubuntu-meta (Ubuntu)

Bug Description

Support for extended attributes is currently extremely lacking to non-existent, even if the file system supports them. Extended attributes lost when a file is copied or moved, they are lost when editors or other programs update a file by deleting and re-creating it, they are lost when backing up files with tar, rsync or other programs.
There is no support to actually use EAs from GUI programs (e.g. in Nautilus) either.

EA could be a great way to allow both programs (in a hidden way) and users (via a GUI) to add meta-data and annotations to their files, which in turn could be used by Beagle to allow more intelligent searches.

Making this work in a decent way and actually using it in a productive way could mean a major competitive edge over other OS which are still also lacking all these modern features.

Johann Petrak (johann-petrak) wrote :

I have not originally assigned this to component nautilus because many programs are affected. Unless at least the most essential programs like "cp", "mv", "tar", "gedit" etc. all maintain/handle existing EAs, support in nautilus is pretty useless.

andreimatei (andreimatei1) wrote :

EAs should at least be enabled. For example, Beagle uses them if they are available. There is even a page ( that tells you how to enable them.

Peter Sabaini (peter-sabaini) wrote :

I agree, EA-aware coreutils and some basic tools like tar with EA support would be marvellous; ATM there is virtually no way to use extended attributes in ubuntu

HonoredMule (honoredmule) wrote :

What is the status on this? I just started using the calendar server package and quickly discovered that I've adopted a ticking time bomb; backups will be completely useless if the extended attributes are not preserved.

I want to do an ext4 reformatting and fresh install of my server, porting much of my existing configuration/data onto it. But the unsatisfied need to copy xattr metadata to another physical location is an arcane hindrance reminiscent of Linux in 1992. It seems almost embarrassing to think there might actually be no feasible way to accomplish such a basic and necessary task.

Are there even any workarounds floating around, like a bash or perl script that recursively copies directories and then copies the metadata, or recursively extracts the metadata from a directory and then re-applies it to another directory with matching contents? Even if the data could not be preserved in a portable format for later restoration, at least that would be something.

SabreWolfy (sabrewolfy) wrote :

Some info on enabling this in Ubuntu ( but I've not tested it myself.

Would be nice to have an alternative to the rather buggy ( Nautilus Notes.

HonoredMule (honoredmule) wrote :

SabreWolfy, I think you need to re-read this bug. It has nothing to do with the filesystem itself supporting extended attributes. Rather the problem is with all the user-land tools that do not, like cp, tar, graphical file managers, etc.

Without these tools supporting them, filesystem support is useless in most situations. Of course, only Apple is stupid enough to design software that won't work without them and depends utterly on this metadata being preserved, which is why the issue does not arise more commonly. There wouldn't be that much need for the support otherwise.

John Baptist (jepst79) wrote :

As a start, it seems to me that EA-aware mechanisms could be added to the generic GTK+ file-handling functions. Then all GTK+ apps, including all GNOME apps, would get that benefit immediately. EAs would be preserved through most GUI operations, if not through coreutils operations.

HonoredMule (honoredmule) wrote :

That may be fine for desktops, but where we were really devoid of options is on servers. The latest release (Ibex) in server edition now supports copying extended attributes with --preserve=all or the archive flag (-a). However it still failed when copying between two xattr-enabled partitions. I don't remember what finally worked. I did play with "star" a lot, which successfully made a backup of my data and restored it to another partition on the old install, but couldn't do the same on the new, using the same commands as before:

Backup: star -c -dump path/to/backup >
      (Add -z to gzip output, -bz to bzip it.)
Restore: star xvf target/restore/path -dump
      (Cannot directly restore compressed version.)

Whatever finally worked, I had to spend an afternoon faffing about to accomplish it.
Then I found out Ibex's calendarserver package is broken. /facepalm

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers