Extended file attributes: Difference between revisions

Revision as of 22:33, 4 December 2020

Latest revision as of 22:51, 18 July 2025

(28 intermediate revisions by 20 users not shown)

Line 1:

{{Short description|Set of file system features}}

'''Extended file attributes''' are [[file system]] features that enable users to associate [[computer file]]s with [[metadata]] not interpreted by the filesystem, whereas regular attributes have a purpose strictly defined by the filesystem (such as [[file system permissions|permissions]] or records of creation and modification times). Unlike [[fork (file system)|forks]], which can usually be as large as the maximum file size, extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses include storing the author of a document, the [[character encoding]] of a plain-text document, or a [[cyclic redundancy check|checksum]], [[cryptographic hash]] or [[digital certificate]], and [[discretionary access control]] information.

In [[Unix-like]] systems, extended attributes are usually abbreviated as '''xattr'''.<ref>{{man|7|xattr|Linux}}</ref>

== Implementations ==

Line 11 ⟶ 12:

| work=IBM [[AIX]] V7.2 documentation

| publisher=[[IBM]]

| accessdateaccess-date=2017-07-11}}</ref> The {{mono|getea,}},<ref>{{cite web

| url=https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.basetrf1/getea.htm

| title=getea Subroutine

| work=IBM AIX V7.2 documentation: Base Operating System and Extensions, Volume 1

| publisher=IBM

| accessdateaccess-date=2017-07-11}}</ref> {{mono|setea}},<ref>{{cite web

| url=https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.basetrf2/setea.htm

| title=setea Subroutine

| work=IBM AIX V7.2 documentation: Base Operating System and Extensions, Volume 2

| publisher=IBM

| accessdateaccess-date=2017-07-11}}</ref> {{mono|listea}},<ref>{{cite web

| url=https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.basetrf1/listea.htm

| title=listea Subroutine

| work=IBM AIX V7.2 documentation: Base Operating System and Extensions, Volume 1

| publisher=IBM

| accessdateaccess-date=2017-07-11}}</ref> {{mono|statea}},<ref>{{cite web

| url=https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.basetrf2/statea.htm

| title=statea Subroutine

| work=IBM AIX V7.2 documentation: Base Operating System and Extensions, Volume 2

| publisher=IBM

| accessdateaccess-date=2017-07-11}}</ref> and {{mono|removeea}}<ref>{{cite web

| url=https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.basetrf2/removeea.htm

| title=removeea Subroutine

| work=IBM AIX V7.2 documentation: Base Operating System and Extensions, Volume 2

| publisher=IBM

| accessdateaccess-date=2017-07-11}}</ref> APIs support fetching, setting, listing, getting information about, and removing extended attributes.

=== OpenBSDBeOS/Haiku ===

In the now-defunct [[BeOS]] and successors like [[Haiku (operating system)|Haiku]], extended file attributes are widely used in base and third-party programs.

Support for extended file attributes was removed from the [[OpenBSD]] source code in 2005 due to a lack of interest in [[Access Control Lists]]<ref>{{cite web |title=CVS log for src/sys/ufs/ufs/Attic/extattr.h |url=https://cvsweb.openbsd.org/src/sys/ufs/ufs/Attic/extattr.h|date=2005-07-03|author=Dale Rahn}}</ref>

The [[Be File System]] allows the indexing and querying of attributes, essentially giving the filesystem [[Relational Database|database]]-like characteristics. The uses of extended attributes in Be-like systems are varied: For example, [[Tracker (file manager)|Tracker]] and [[OpenTracker]], the file-managers of BeOS and Haiku respectively, both store the locations of file icons in attributes,<ref>{{cite web |title=Attributes |url=https://www.haiku-os.org/docs/userguide/en/attributes.html |website=Haiku User Guide |publisher=Haiku, Inc. |access-date=28 January 2021}}</ref> Haiku's "Mail" service stores all message content and metadata in extended file attributes,<ref>{{cite web |title=Workshop: Managing Emails |url=https://www.haiku-os.org/docs/userguide/en/workshop-email.html |website=Haiku User Guide |publisher=Haiku, Inc. |access-date=28 January 2021}}</ref> and the MIME types of files are stored in their attributes. Extended file attributes can be viewed and edited in Be-like systems' GUI through the file-manager, often Tracker or derivatives thereof.

=== FreeBSD ===

Line 46 ⟶ 48:

===Linux===

In [[Linux]], the [[ext2]], [[ext3]], [[ext4]], [[JFS (file system)|JFS]], [[Squashfs]], [[UBIFS]], [[YAFFS|Yaffs2]], [[ReiserFS]], [[Reiser4]], [[XFS]], [[Btrfs]], [[OrangeFS]], [[Lustre (file system)|Lustre]], [[OCFS2|OCFS2 1.6]], [[ZFS]], and [[F2FS]]<ref>{{cite web

| url=httphttps://lkml.iu.edu/hypermail/linux/kernel/1210.0/03190.html

| title=[PATCH 13/16] f2fs: add xattr and acl functionalities

| first=Jaegeuk

| last=Kim

| date=2012-10-05

| accessdateaccess-date=2017-07-11}}</ref> filesystems support extended attributes (abbreviated ''xattr'') when enabled in the kernel configuration. Any regular file or directory may have extended attributes consisting of a name and associated data. The name must be a [[null-terminated string]] prefixed by a [[namespace]] identifier and a dot character. Currently, four namespaces exist: user, trusted, security and system. The user namespace has no restrictions with regard to naming or contents. The system namespace is primarily used by the kernel for [[access control list]]s. The security namespace is used by [[SELinux]], for example.

Support for the extended attribute concept from a POSIX.1e draft{{cn|date=July 2020}} that had been withdrawn<ref>{{cite newsgroup | url=https://groups.google.com/g/comp.security.unix/c/gfyLMetqubs/m/hipaUcdWosAJ | title=Posix.1e? |first=Casey |last=Schaufler |date=2002-04-30 |newsgroup=comp.security.unix}}</ref> in 1997 was added to Linux around 2002.<ref>{{cite web

| title=v2.5.3 git commit log

| url=https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/include/?id=1ea864f1c53bc771294e61cf9be43b1d22e78f4c

| date=2002-02-05

| accessdateaccess-date=2017-07-11}}</ref><ref>{{cite web

| url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Release_Notes/as-x86/index.html

| title=Red Hat Enterprise Linux AS 3 Release Notes (x86 Edition)

Line 64 ⟶ 66:

| year=2003

| publisher=[[Red Hat]]

| archive-url=https://web.archive.org/web/2015122117322420170709142229/https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Release_Notes/as-x86/index.html

| archive-date=20152017-1207-2109

| url-status=dead

| accessdateaccess-date=2017-07-11}}</ref>

As of 2016, they are not yet in widespread use by user-space Linux programs, but are used by [[Beagle (software)|Beagle]], [[OpenStack#Object Storagestorage .28Swift.29(Swift)|OpenStack Swift]], [[Dropbox (service)|Dropbox]], [[KDE]]'s semantic metadata framework (Baloo), [[Chromium (web browser)|Chromium]], [[Wget]] and, [[cURL]]., A set of recommendations for using them is available atand [[freedesktop.orgSnap_(software)#Snapcraft|Snapcraft]].<ref>{{cite web

| url=https://www.freedesktop.org/wiki/CommonExtendedAttributes/

| title=Guidelines for extended attributes

| date=2013-05-18

| accessdate=2017-07-11}}</ref>

The Linux kernel allows extended attributeattributes to have names of up to 255 bytes and values of up to 64KiB64 KiB,<ref>{{cite web

| url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/limits.h?id=607ca46e97a1b6594b29647d98a32d545c24bdff#n15

| title=linux/include/uapi/linux/limits.h

| date=2012-10-13

| accessdateaccess-date=2017-07-11}}</ref>

as do [[XFS#Extended attributes|XFS]] and [[ReiserFS]], but [[ext2]]/[[ext3|3]]/[[ext4|4]] and [[btrfs]] impose much smaller limits, requiring all the attributes (names and values) of one file to fit in one "filesystem block" (usually 4 KiB). Per POSIX.1e,{{cn|date=July 2020}} the names are required to start with one of ''security'', ''system'', ''trusted'', and ''user'' plus a period. This defines the four namespaces of xattrsextended attributes.<ref>{{man|7|xattr|Linux}}</ref>

as do [[XFS#Extended attributes|XFS]] and [[ReiserFS]],

but [[ext2]]/[[ext3|3]]/[[ext4|4]] and [[btrfs]] impose much smaller limits, requiring all the attributes (names and values) of one file to fit in one "filesystem block" (usually 4 KiB). Per POSIX.1e,{{cn|date=July 2020}} the names are required to start with one of ''security'', ''system'', ''trusted'', and ''user'' plus a period. This defines the four namespaces of xattrs.<ref>{{man|7|xattr|Linux}}</ref>

Extended attributes can be accessed and modified using the <code>getfattr</code> and <code>setfattr</code> commands from the <code>attr</code> package on most distributions.<ref>{{cite web

Line 85 ⟶ 83:

| url=https://savannah.nongnu.org/projects/attr/

| website=[[GNU Savannah]]

| accessdateaccess-date=2017-07-11}}</ref> The APIs are called {{code|getxattr}} and {{code|setxattr}}.

===macOS===

[[Mac OS X Tiger|Mac OS X 10.4]] and later support extended attributes by making use of the [[HFS Plus|HFS+]] filesystem Attributes fileFile [[B*-tree]] feature which allows for named forks. Although the named forks in HFS+ support arbitrarily large amounts of data through extents, the OS support for extended attributes only supports inline attributes, limiting their size to that which can fit within a single B*-tree node.{{citation needed|date=September 2012}} Any regular file may have a list of extended attributes. HFS+ supports an arbitrary number of named forks, and it is unknown if [[macOS]] imposes any limit on the number of extended attributes.

Each attribute consists of a name and the associated data. The name is a [[null-terminated string|null-terminated]] [[Unicode]] string. No namespace restrictions are present (making this an ''open xattr'' system) and the convention is to use a reverse DNS string (similar to [[Uniform Type Identifier]]s) as the attribute name.

Line 95 ⟶ 93:

Since macOS 10.5, files originating from the web are marked with <code>com.apple.quarantine</code> via extended file attributes.<ref>{{cite web |title=Launch Services Release Notes |url=https://developer.apple.com/library/archive/releasenotes/Carbon/RN-LaunchServices/index.html |website=developer.apple.com}}</ref> In some older versions of macOS (such as [[Mac OS X Snow Leopard|Mac OS X 10.6]]), user space extended attributes were not preserved on save in common [[Cocoa (API)|Cocoa]] applications (TextEdit, Preview etc.).{{citation needed|date=October 2012}}

=== OpenBSD ===

Support for extended file attributes was removed from the [[OpenBSD]] source code in 2005 due to a lack of interest in [[Access Control Lists]].<ref>{{cite web |title=CVS log for src/sys/ufs/ufs/Attic/extattr.h |url=https://cvsweb.openbsd.org/src/sys/ufs/ufs/Attic/extattr.h|date=2005-07-03|author=Dale Rahn}}</ref>

===OS/2===

In [[OS/2]] version 1.2 and later, the [[High Performance File System]] was designed with extended attributes in mind, but support for them was also retro-fitted on the [[File Allocation Table|FAT]] filesystem of DOS.

For compatibility with other operating systems using a FAT partition, OS/2 attributes are stored inside a single file "{{code|EA DATA. SF}}" located in the root directory. This file is normally inaccessible when an operating system supporting extended attributes manages the disk, but can be freely manipulated under, for example, DOS. Files and directories having extended attributes use one or more [[cluster (file system)|clusters]] inside this file. The logical cluster number of the first used cluster is stored inside the owning file's or directory's [[FAT extended file attributes|directory entry]].<ref name="os2-fat-extended-attributes">{{cite web

| url=httphttps://www.tavi.co.uk/os2pages/eadata.html

| title=Implementation of extended attributes on the FAT file system

| first=Bob

| last=Eager

| date=2000-10-28

| accessdateaccess-date=2017-07-11}}</ref> These two bytes are used for other purposes on the FAT32 filesystem, and hence OS/2 extended attributes cannot be stored on this filesystem.

Parts of OS/2 version 2.0 and later such as the [[Workplace Shell]] uses several standardized extended attributes (also called ''EAs'') for purposes like identifying the filetype, comments, [[computer icon]]s and keywords about the file.

Line 110 ⟶ 111:

===Solaris===<!-- This section is linked from [[Solaris (operating system)]] -->

[[Solaris (operating system)|Solaris]] version 9 and later allows files to have "extended attributes", which are actually [[fork (file system)|fork]]s; the maximum size of an "extended attribute" is the same as the maximum size of a file, and they are read and written in the same fashion as files. Internally, they are actually stored and accessed like normal files, so their names cannot contain "/" characters<ref>{{man|57|fsattr|Solaris}}</ref> and their ownership and permissions can differ from those of the parent file.

Version 4 of the [[Network File System]] supports extended attributes in much the same way as Solaris.

===Windows NT===

On [[Windows NT]], limited-length extended attributes with names of up to 255 [[ASCII]] characters and values of up to 65535 bytes are supported by [[File Allocation Table|FAT]],<ref name="os2-fat-extended-attributes"/> [[High Performance File System|HPFS]], and [[NTFS]], but without support through the [[Win32]] [[API]]. This was implemented as part of the [[Windows NT 3.1#OS/2|OS/2 subsystem]]. They are notably used by the [[Network File System (protocol)|NFS]] server of the [[Interix]] POSIX subsystem in order to implement Unix-like permissions. The [[Windows Subsystem for Linux]] added in the [[Windows 10#Redstone|Windows 10 Anniversary Update]] uses them for similar purposes, storing the Linux file mode, owner, device ID (if applicable), and file times in the extended attributes.<ref>{{cite web

| url=https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

| title=WSL File System Support

Line 122 ⟶ 123:

| date=2016-06-15

| publisher=[[MSDN]]

| accessdateaccess-date=2017-07-11}}</ref>

Additionally, [[NTFS]] can store arbitrary-length extended attributes in the form of [[NTFS#Alternate data streamsstream .28ADS.29(ADS)|alternate data streams]] (ADS), a type of [[Fork (file system)|resource fork]]. Plugins for the file manager [[Total Commander]], like ''NTFS Descriptions'' and ''QuickSearch eXtended'' support filtering the file list by or searching for metadata contained in ADS.<ref>{{cite web|url=https://totalcmd.net/plugring/NTFS_diz.html|title=NTFS Descriptions 1.2.1|website=TotalCmd.net|accessdateaccess-date=16 April 2018}}</ref><ref>{{cite web|url=httphttps://totalcmd.net/plugring/google_like_qs.html|title=QuickSearch eXtended|website=TotalCmd.net|accessdateaccess-date=16 April 2018}}</ref> [[NTFS-3G]] supports mapping ADS to extended attributes in [[Filesystem in Userspace|FUSE]]; it also maps file attributes that way.<ref>{{cite web |title=Extended Attributes |url=https://www.tuxera.com/community/ntfs-3g-advanced/extended-attributes/ |website=Tuxera |archive-url=https://web.archive.org/web/20200814021136/https://www.tuxera.com/community/ntfs-3g-advanced/extended-attributes/ |archive-date=2020-08-14 |url-status=dead}}</ref>

==See also==