[FEAT] XDG Extended Attribute spec support

[avidseeker]

XDG Extended Attributes guidelines include metadata about files that is supported on the file system level. Many programs attach this metadata to downloaded or produced files, and it would seem an essential feature for a file manager to provide a way to view and edit this metadata. In particular, these xattrs are of high relevance:

    user.xdg.comment: supported by Dolphin and other file managers.
    user.xdg.origin.url: for files downloaded from a url.
    user.xdg.robots.index: "true" if a file is included in indexing, "false" otherwise
    user.xdg.robots.backup: "true" if a file is included in backup, "false" otherwise
    user.xdg.language
    user.xdg.creator
    user.xdg.publisher
    user.xdg.origin.email.subject
    user.xdg.origin.email.from
    user.xdg.origin.email.message-id

Implementation:

• Add viewer/editor when checking file properties and permissions.
• Add columns when in list view showing tags, and other relevant XDG attributes.

[p3732 (Peter Eisenmann)]

Hi, the spec says “These attributes are currently proposed”, so calling them “an essential feature” seems like quite a stretch. I don’t think that a merge request that implements showing them would necessarily be dismissed, especially ‘comment’ might be interesting to have, since Dolphin supports it, but as long as the spec is merely a proposal, I don’t see any urgency for Files to support them.

[antoniof (António Fernandes)]

Many programs attach this metadata to downloaded or produced files

Can you provide a list?

[avidseeker]

It is an essential feature regardless of the standard. Just as a note, XDG isn’t the only standard. Take a look on Dublin Core. I’m saying it’s “essential” because file managers should tell you everything about files at least from the file system level. So just like it tells you about timestamps, ownership and permissions and allows you to edit them, it should also do the same for extended attributes.

@antoniof

Can you provide a list?

It’s not currently widely supported (E.g: Chromium browsers used to attach xdg.origin.url and xdg.referrer.url), but in general download managers like curl, wget, youtube-dl have --xattrs option.

[antoniof (António Fernandes)]

So, “many programs” turns out to be few, and “essential feature” turns out to be a personal wishlist.

I’m still interested in learning more about this proposal and how we can take advantage of it to improve user experience.

From now on, I kindly request a honest conversation without misleading statements that hurt trust.

[antoniof (António Fernandes)]

Looking at the examples provided at the top post, I think user.xdg.origin.email.from and user.xdg.origin.url could be put to good use in the Downloads directory by displaying the origin source of the file.

So, I looked more into this in hopes to have a nice new feature.

What do I found was not favourable:

Chromium removed support years ago because xattrs are unsecure a9b4fb70b4318b220deee0da7b1693d16b8ed071 - chromium/src - Git at Google

Firefox hasn’t added it for the same reason 665531 - [Linux] Store that file was downloaded from the Internet (Extended Attribute user.xdg.origin.url)

So, the two major browsers won’t support this, which completely kills the idea.

[antoniof (António Fernandes)]

The reality is, as I wrote in a previous thread, that the “user.*” class of extended attributes doesn’t have a success story to tell for almost two decades.

The information in the CommonExtendedAttributes page linked in the top post is very old and outdated. The fact it even mentions “Beagle” signals its antiquity. It should probably have a warning “THE INFORMATION ON THIS PAGE IS OBSOLETE.” to avoid wasting everyone’s time on a dead end.

It didn’t gain traction at the time where filesystem-based metadata was a cool new thing. So, let’s be real: it won’t gain traction now.

[p3732 (Peter Eisenmann)]

In https://connect.mozilla.org/t5/ideas/add-user-xdg-origin-url-attribute-to-downloaded-files/idc-p/23276/highlight/true#M12506 it is pointed out that Firefox does actually save gvfs “metadata::download-uri”. Looking at my downloads folder I can confirm this, though the information happens to be pretty useless for my files.

[antoniof (António Fernandes)]

gvfs-metadata being a local database makes it safer than xattrs which can be leaked when transferring the file elsewhere.

Unfortunately no other web browser does this. We could try to get epiphany on board.

Still, this being information that’s not always present, a column in list view is probably not the right way to display it. Maybe a caption? Maybe a button which opens a popover (like search snippets)?

[p3732 (Peter Eisenmann)]

I would expect it to be displayed in properties. I don’t consider it important enough for showing it in the view in some way.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart)]

@antoniof

gvfs-metadata being a local database makes it safer than xattrs which can be leaked when transferring the file elsewhere.

Unfortunately no other web browser does this.

Partially by design at times, per https://bugzilla.mozilla.org/show_bug.cgi?id=1535950. However, why not request support for it yourself at https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm|Firefox, @antoniof? Per [FEAT] XDG Extended Attribute spec support - #8 by p3732, it doesn’t seem like the choice to not support it in its entirety is delibrate.

[antoniof (António Fernandes)]

@rokejulianlockhart

why not request support for it yourself at Log in to Bugzilla, @antoniof?

Sorry, I’m not understanding. Request Firefox support for what?

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart)]

Doesn’t matter, @antoniof. If you don’t know what I was referring to with that quotation, you obviously didn’t want what I expected you wanted. Apologies.