Most users are familiar with the usual file attributes. Desktop file managers often list them as properties: the name, path, size, and the dates that the file was created, last accessed, and last modified (Figure 1). Many, too, are familiar with the separate read, write, and execution permissions for a file's owner, group, and other users. However, over the decades, new filesystems, as well as the needs of version control for developers, have developed additional optional attributes. These additional attributes are edited by chattr [1], the equivalent for chown and chmod for permissions, and can be viewed by lsattr [2]. Both commands are included in the e2fsprogs [3] package and are installed by default in most distributions. While the creation of chattr and lsattr was driven by the needs of developers, many of these additional attributes are practical for everyday use as well.

Figure 1: The standard file attributes are displayed in Plasma's Dolphin file manager. Also note the Permissions tab.

chattr and lsattr Options

The commands for working with file attributes have limited options. All options use a single letter rather than the full word like GNU style. In chattr, the -f option will suppress all except critical error messages. However, users are more likely to want -R (recursive) to change the attributes of an entire directory or -V (verbose) to receive instant feedback. Developers may want to use -v VERSION together with version control, or -p PROJECT to associate files with a particular project. For commands, chattr uses a standard structure:

chattr [OPTIONSP [-v VERSION] [-p PROJECT] [OPERATOR][ATTRIBUTES ][FILES]

Version (-v VERSION) and project (-p project) are optional. They correspond to directory names and may be placed anywhere after options. One of the three operators shown in Table 1 must be given.

By default, chattr does not return any output, but using the verbose (-V) option returns the same information as lsattr (Figure 2).

Figure 2: The verbose option in chattr, with three attributes added, can simulate lsattr's output.

Like chattr, lsattr uses the same options, as well as others. However, its main options set how output is displayed. With -a, the output includes hidden files, while -d lists directories without their contents. For those who want readability without reference to the man page, -l prints the long names of attributes, rather than their one-character abbreviations. In addition, -p lists the project, and -v the file's version. Remember that normal permissions determine which files each user can view. Unlike chattr, lsattr is edited with the structure you might expect, with the basic command followed by options, followed by the target files (Figure 3).

Figure 3: lsattr displays the attributes of all the files in a directory. The e attribute indicates that the system's files use extents for mapping the blocks on disk. This attribute cannot be removed using chattr.

Selected Attributes

Each attribute is assigned a single uppercase or lower-class letter. Each attribute is given a paragraph in the man page, but the mnemonic abbreviation in the documentation (aAcCdDeFijmPsStTux) is not much help, especially because letters sometimes seem to be assigned to attributes randomly. To make more sense of the attributes, here are some of the most useful attributes, arranged by category.

As might be expected, the largest category of attributes affect how files are edited. With the C attribute, copy-on-write (the resource management tool that only creates duplicates of files when one is modified) is suppressed. If applied to a directory that uses copy-on-write, existing files are unchanged, but new files take on the attribute. By contrast, D writes two files or directories recursively and at the same time, ensuring that they are identical, just like the dirsync command [4]. The same function is had for file attributes using S. When editing a file, a only allows content to be added at the end of the file, while i prevents a file from being edited, renamed, or deleted. Alternatively, V uses the kernel's fs-verity feature [5] to have all operations that use the file checked against a cryptographic hash – a so-called Merkle tree [6] – and also makes the file undeletable. Conversely, when a file is deleted, J saves all data on an ext4 system to journal, while u saves a file so that chattr can undelete it. For security, a file can also be overwritten with zeros to keep it from being retrieved.

Other normal file operations can also be affected by attributes. For instance, E encrypts, and d excludes a file in a backup done with dump. With c, a file is compressed, while m prevents a file from being compressed. Developers using chattr might want to use P to enforce a project's directory hierarchy. Given the tendency of Linux users to write entirely in lowercase, many users might also want to use I, which allows a file's path to be entered without uppercase characters.

Due to the variety of modern filesystems, all attributes may not work on all filesystems. For instance, applying t to ext2, ext3, or ext4 filesystems is pointless, because it suppresses tail merging, which these filesystems do not support. Some filesystems, too, may have limitations on certain attributes. As well, chattr cannot delete all attributes, such as N, which stores data in the inode. Check, too, for limitations on other attributes. Because of these limitations, I recommend checking the man page for chattr before assigning an attribute. Usually, an unremovable attribute can still be read by lsattr.

The Future of Attributes

Because chattr and lsattr include legacy support, not all attributes may be relevant today. For example, one reason for the A attribute, which does not write atime (the last time a file was accessed) was to reduce the wear on SSD drives when they were originally introduced and had shorter life spans than mechanical hard drives and laptops. However, modern SSD drives can outlast hard drives, so except on machines that are a decade or older, applying the A option has little point. Similarly, on immutable distributions such as Fedora's Silverblue, the i option could become obsolete, at least for system files, because its attribute is automatically used.

However, that still leaves plenty of useful options for chattr and lsattr. No doubt, too, unique features on one filesystem will become usable on others, and new needs will evolve, making chattr and lsattr more useful than ever in the Linux toolbox