Tuxera

Extended attributes are properties organized in (name, value) pairs, optionally set to files or directories in order to record information which cannot be stored in the file itself. They are supported by operating systems such as Windows, Linux, Solaris, MacOSX and others, with variations.

On Linux, specifically, four categories of extended attributes have been defined :

• trusted : to record properties which should only be accessed by the kernel,
• security : to record security properties of a file,
• system : to record other system related properties on which the file owner has some control,
• user : to record properties defined by applications.

The names of the extended attributes must be prefixed by the name of the category and a dot, hence these categories are generally qualified as name spaces. Examples of extended attribute names aresecurity.selinux, system.posix_acl_access or user.mime_type. However a high-level language may hide the system prefixing so that, for instance, the user.mime_type attribute name would appear as“mime_type” in a source code.

They can be retrieved and set through system calls (getxattr(2), setxattr(2), removexattr(2)) or shell commands (getfattr(1), setfattr(1)), provided appropriate access conditions are met :

The extended attributes are enabled through the mount option streams_interface=xattr. With this option (activated by default), the four name spaces are supported by ntfs-3g on Linux.

The extended attributes in user name space are stored on NTFS as alternative data streams whose name is the unprefixed name of the attribute, and whose contents is the value of the attribute. They can be read and modified in Windows by using the standard file access functions, with a colon and the stream name (which is the unprefixed extended attribute name) appended to the file name.

Example :

(the green part is executed on Linux, the purple part is executed on Windows, the Linux file /media/tmp/xattr/file is the same physical file as k:tests\xattr\file on an NTFS partition)

[user xattr]$ # Set the extended attribute "user.color" with
[user xattr]$ # value "green"
[user xattr]$ setfattr -n user.color -v green \
[user xattr]>     /media/tmp/tests/xattr/file
[user xattr]$ # Check the value of the attribute
[user xattr]$ getfattr -n user.color /media/tmp/tests/xattr/file
getfattr: Removing leading '/' from absolute path names
# file: media/tmp/tests/xattr/file
user.color="green"

D:\xattr>REM On windows display the alternative stream "color"
D:\xattr>more < k:tests\xattr\file:color
green
D:\xattr>REM Change the alternative stream contents to "white"
D:\xattr>echo white > k:tests\xattr\file:color
D:\xattr>more < k:tests\xattr\file:color
white

[user xattr]$ # Back on Linux, display the extended attribute
[user xattr]$ # "user.color"
[user xattr]$ getfattr -n user.color /media/tmp/tests/xattr/file
getfattr: Removing leading '/' from absolute path names
# file: media/tmp/tests/xattr/file
user.color="white"

 
A few extended attributes in the system name space are used to give access to NTFS internal data which cannot be accessed through Linux standard methods. They can be accessed with any setting of the option streams_interface. They are not returned when the extended attribute list is queried, and consequently, unless stated otherwise, they are not saved by tar with option --xattrs to avoid conflicts with POSIX ACL and symbolic link savings, but specific tools may be designed to save and restore them.

The following sections describe how to access a few NTFS internal data as extended attributes.

NTFS Attributes

The NTFS attributes are a set of miscellaneous flags associated with a file or directory.

The NTFS attributes are mapped to a four-byte word extended attribute named system.ntfs_attrib whose value is represented with the endianness of the processor used.

Only eight flags can be changed. The system flag (FILE_ATTRIBUTE_SYSTEM) is used in symbolic links and special files, it should not be changed unawares. The compressed flag on a directory is only used when creating new files into the directory, it has no effect on existing files. The other changeable flags are not used by Linux.

Examples :

# Display the current NTFS attributes of the file source-file
getfattr -h -e hex -n system.ntfs_attrib source-file

# Set the NTFS read-only flag to file target-file
# (on a small-endian computer)
setfattr -h -v 0x01000000 -n system.ntfs_attrib target-file

Reparse Data

NTFS use reparse data to define special actions before opening a file or directory. For instance reparse data is used to define Windows junctions and symlinks.

If present, the reparse data of a file or directory is mapped to an extended attribute named system.ntfs_reparse_data, and is returned as a raw variable-length record of small-endian items.

Please note :

• Setting invalid reparse data may have adverse consequences, as no check can be done when setting new data,
• when creating or deleting a junction or symlink by setting or deleting reparse data, the status of the file is not updated in the system caches and subsequent actions on the file may fail. The caches can be updated by setting the owner again after the reparse data change.
• for creating a junction or symlink by setting reparse data, the type of the target (plain file or directory) must match the type of the source on which the reparse data is set.

Examples :

# Display the reparse data of the file source-file
getfattr -h -e hex -n system.ntfs_reparse_data source-file

# Copy the reparse data of the file source-file
# to the file target-file
REPARSE=`getfattr -h -e hex -n system.ntfs_reparse_data source-file | \
         grep '=' | sed -s 's/^.*=//'`
setfattr -h -v $REPARSE -n system.ntfs_reparse_data target-file

NTFS ACLs

The NTFS ACLs are used to control access to files or directories. On linux they are translated into ownership, permissions and Posix ACLs parameters.

The NTFS ACL of a file or directory is mapped to an extended attribute named system.ntfs_acl, and is returned as a raw variable-length record of small-endian items. All the components of the ACL are returned : the owner id, the group id, the discretionary ACL and the system ACL.

The setting of a new NTFS ACL is rejected is the consistency check fails.

Examples :

# Display the NTFS ACL of the file source-file
getfattr -h -e hex -n system.ntfs_acl source-file

# Copy the ACL of the file source-file to the file target-file
ACL=`getfattr -h -e hex -n system.ntfs_acl source-file | \
         grep '=' | sed -s 's/^.*=//'`
setfattr -h -v $ACL -n system.ntfs_acl target-file

DOS names

An NTFS file may have an alternate short name to enable access by legacy application which can only process files whose name complies to a 8.3 pattern (the main part of the name has at most 8 characters, followed by a dot and a suffix which has at most 3 characters). Linux usually does not use such short names.

The short name of a file can be queried and set as if it were the value of an extended attribute named system.ntfs_dos_name. When there is a short name, the character set used to build both the short and the long name is restricted : control characters (whose code is less than 0×20) and nine specific characters (<>:”\/|?*) are not allowed in either name. As a consequence no short name can be set on a file whose existing name contains forbidden characters.

The Windows algorithm to derive a short name from a long name is not enforced by Linux, only the character set and the unicity of case-sensitive names are checked. When queried, the short name is always capitalized.

Please note :

• in a directory a file cannot have several short names and associated long names (same as Windows)
• setting a DOS name requires having write access to the parent directory

Examples :

# Display the short name of the file source-file
getfattr -h -n system.ntfs_dos_name source-file

# Set TARGET~1 as the short name of the file target-file
setfattr -h -v "TARGET~1" -n system.ntfs_dos_name target-file

File times

An NTFS file is qualified by a set of four time stamps “representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)”, though UTC has not been defined for years before 1961 because of unknown variations of the earth rotation. These are:

• the time the file was created,
• the time the file was last written or truncated
• the time the file was last accessed,
• the time some attribute of the file was last changed

These times are mapped to an extended attribute named system.ntfs_times as an array of 64-bit quantities in the above order, represented with the endianness of the processor used. All four times can be queried, but only the first three can be set, as the last one records, for unknown purpose, the time of any change (possibly journalling, mirroring or backup).

Object Ids

(since ntfs-3g-2009.11.14AB.1)

Object ids (OIDs, also called GUIDs or UUIDs) are 16-byte labels identifying objects unambiguously. On NTFS, files and directories may have their own local OID which points to the initial OID of the file concatenated to the OID of the volume and the domain on which the file was initially created (64 bytes in all). The OID can thus be used to find files and directories which were relocated (see MSDN)

The full GUID of a file is mapped to an extended attribute named system.ntfs_object_id as a sequence of 64 bytes.

EFS Info

EFS is the methodology used in NTFS to deal with encrypted files. An encrypted file consists of the user data, encoded such that an unauthorized person is not able to interpret it, and the decryption information, the EFS Info, which contains the key, encrypted so that only authorized people can get it in order to interpret the user data.

The decryption information is mapped to an extended attribute named user.ntfs.efsinfo. It can thus be retrieved and recreated, so that backup applications can blindly save and restore encrypted files and associated data without interpreting anything. The EFS info is specific to a file, so the file contents, its user extended attributes and the EFS info have to be kept associated.

Reading and writing raw encrypted data and decryption information are only possible when using the mount option efs_raw. This causes the size of the raw data to appear slightly bigger than the original data.

Please note: encryption and compression are not compatible. Do not restore an encrypted file into a directory marked for compression.