Talk:Extended file attributes

BeOS

How come this page does not even mention BeOS, one of the largest and earliest massive user of xattrs ??? Need to fix this ASAP, unless someone else has the time... Mmu man (talk) 15:28, 23 February 2010 (UTC)

Good point. Can anyone help? (I've left a message on user talk:Mmu man.) CWC 21:58, 23 February 2010 (UTC)

I'll be looking into it when I have time. Mmu man (talk) 14:32, 3 March 2010 (UTC)

AmigaOS

AmigaOS supported a type of extended attributes via the optional .info "icon" files. It also supported a comment string per file with support from the file system (although this was not strictly speaking general-purpose extended attributes, only a single comment attribute). 66.11.179.30 (talk) 15:51, 21 July 2010 (UTC)

OpenBSD

There is mention of OpenBSD chflags(1), but this seems to be supported by all BSDs and to only allow changes of a flag of bit fields, internally using the chflags(2)/lchflags(2) syscalls (inherited from NetBSD, and formerly from 4.4BSD). I don't have access to an OpenBSD system at the moment, but does it really allow arbitrary user extended attributes using that facility? If not that's IMO something else than the general extended attributes this article seems to be about...66.11.179.30 (talk) 15:47, 21 July 2010 (UTC)

Yes, those are just the generic *BSD/Mac OS X "BSD flags". I've removed that section. Guy Harris (talk) 20:06, 17 January 2012 (UTC)

FreeBSD

Does ZFS on FreeBSD support extended attributes? The article currently states that "Since FreeBSD 8.0, extended attributes are also supported on ZFS filesystem. [citation needed]", but the current FreeBSD 10.2 ZFS man page states "The xattr property is currently not supported on FreeBSD.". I'm going to be bold and remove this statement. If anyone has a good pointer, it is appreciated if you could add it back to the main page. MacFreek (talk) 14:32, 7 November 2015 (UTC)

Good move. Poking around the FreeBSD website, I found that their extended attributes facility seems to use two fields in the on-disk UFS2 inode structure, di_extsize and di_extb, allowing up to two blocks of xattr data. However, ZFS uses the same approach as Solaris and NFS4: each file and directory N can have a 'hidden' directory in which each file is an attribute of N, represented by a optional block address for that directory in their on-disk inodes. For FreeBSD to support xattrs in ZFS without changing the on-disk structures, they would need code to safely map Solaris-style on-disk attributes to/from BSD-style attributes. Which would be hard to design, harder to write and very bloody difficult to make robust.

Cheers, CWC 02:40, 8 November 2015 (UTC)

And yet it works just fine since... No idea, I've fixed a permissions bug there somewhere in 2008. So it's been available for about a decade now. Trasz (talk) 14:08, 29 June 2017 (UTC)

Linux - getfattr and lsattr

I think the Linux "lsattr" command cannot be actually used for displaying these "extended file attributes" (ie the name/value pairs); instead it shows the "file attributes on a Linux second extended file system" (ie. some special file-system attributes related to storage mode of a file). IIUC these are completely different file attributes. There's some explanation of this at http://c50k.com/acl.html .

I think the mention of lsattr should be removed here, and instead could be added in some other article (maybe related to Linux file systems?). — Preceding unsigned comment added by 82.83.219.157 (talk) 21:30, 6 December 2015 (UTC)

Metadata on Linux Suggestion

In the sentence ...

Support for the extended attribute concept from a POSIX.1e draft that had been withdrawn in 1997 was added to Linux around 2002

... there is a word missing after '1997'. Which word would that be?

Can someone who knows better than me add infos about simple to use Linux derivates which support this out of the box? And an example how to add such metadata? That would be a nice info to have here. Heronils (talk) 09:18, 28 October 2017 (UTC)

Overlap with Fork (file system)

The concept of extended attributes is quite similar to (named) forks: both are a named sequence of bytes associated with a file, distinct from the file's regular data. Going by the definitions in Extended file attributes and Fork (file system), the main difference is that xattrs usually have a strict size limit, whereas forks don't.

The content of the two articles overlaps too. Both have a list of OSes and file systems implementing xattrs and forks. Currently, Extended file attributes lists 9 implementations and Fork (file system) lists 4 implementations. 3 of them (Apple/macOS, Microsoft/Windows, Sun/Solaris) are listed in both articles, mostly duplicated with some (apparently unintentional) differences in wording and content. This isn't great.

What would be a good way to address this duplication? Try to classify each implementation as either "forks" or "extended attributes" and delete the duplicate description on the other page? (If so, what should be done for ambiguous/debatable cases like Solaris xattrs and Windows ADSes?) Or would it make more sense to merge the two articles, so that there's a single list of all systems that implement something like xattrs and/or forks? dgelessus (talk) 15:06, 1 January 2026 (UTC)

ambiguous/debatable cases like Solaris xattrs and Windows ADSes? Presumably Windows ADSes are ambiguous because NTFS, as far as I know, supports arbitrary-length streams, while ReFS ADSes are limited in size. For Solaris, are one or more of UFS, ZFS, or tmpfs extended attributes limited in size? Guy Harris (talk) 00:03, 3 January 2026 (UTC)

Plus NTFS supports both ADSes and OS/2 extended attributes, although I'm not sure the latter were ever exposed through the Windows API (as opposed to the Native API). The ReFS article claims support for OS/2 extended attributes were added along with limited-length ADSes in a later release. Guy Harris (talk) 00:39, 3 January 2026 (UTC)

By "ambiguous/debatable" I mean "it's not immediately obvious which of the two pages is the more appropriate place for this implementation". Windows ADSes are generally like forks (especially in contrast to the OS/2-derived extended attributes), but if you take the size-based definition literally, ReFS ADSes would count as extended attributes due to the size limit... (I'm not arguing that ADSes should be moved to Extended file attributes just because of that though - I'm just trying to follow the logic.)

With Solaris xattrs, the issue is that they seem to be forks in all but name. Solaris xattrs are apparently full-featured files that are accessed via the standard Unix file system APIs, which definitely better fits the description of Fork (file system). But they're called xattrs or "extended file attributes", so readers will probably expect to find them at Extended file attributes... (I have no personal experience with Solaris, so I don't know if individual file systems impose any size limits or not.)

Anyway, after re-reading both articles, I see that there isn't as much duplication as I first thought. Although macOS and Windows are listed on both articles, they cover different features (Extended file attributes covers Mac xattrs and Windows EAs, whereas Fork (file system) covers Mac resource forks and Windows ADSes), so that makes sense. Solaris is the only one where the content is truly duplicated.

So I guess my remaining question is: where should Solaris go? Do we care more about the official name or about how the feature works? dgelessus (talk) 18:18, 4 January 2026 (UTC)

Given that Solaris "extended attributes" act the same was as Windows ADSes and Mac forks, I'd say that Fork (file system) should contain the bulk of the discussion, and Extended file attributes should note that Solaris has something called "extended attributes" but that are really forks.

For Windows, we should perhaps note that ReFS ADSes are limited in size, so they are, in some ways, like extended attributes. Guy Harris (talk) 18:54, 4 January 2026 (UTC)