Fedora – Can’t set extended attributes on ext4 on fedora 22 – operation not supported

The answer to you question is filesystem specific. For ext3, for example, have a look at fs/ext3/xattr.c, it contains the following description:

  16 /*
  17  * Extended attributes are stored directly in inodes (on file systems with
  18  * inodes bigger than 128 bytes) and on additional disk blocks. The i_file_acl
  19 
 * field contains the block number if an inode uses an additional block. All
  20  * attributes must fit in the inode and one additional block. Blocks that
  21  * contain the identical set of attributes may be shared among several inodes.
  22  * Identical blocks are detected by keeping a cache of blocks that have
  23  * recently been accessed.
  24  *
  25  * The attributes in inodes and on blocks have a different header; the entries
  26  * are stored in the same format:
  27  *
  28  *   +------------------+
  29  *   | header           |
  30  *   | entry 1          | |
  31  *   | entry 2          | | growing downwards
  32  *   | entry 3          | v
  33  *   | four null bytes  |
  34  *   | . . .            |
  35  *   | value 1          | ^
  36  *   | value 3          | | growing upwards
  37  *   | value 2          | |
  38  *   +------------------+
  39  *
  40  * The header is followed by multiple entry descriptors. In disk blocks, the
  41  * entry descriptors are kept sorted. In inodes, they are unsorted. The
  42  * attribute values are aligned to the end of the block in no specific order.
  43  *
  44  * Locking strategy
  45  * ----------------
  46  * EXT3_I(inode)->i_file_acl is protected by EXT3_I(inode)->xattr_sem.
  47  * EA blocks are only changed if they are exclusive to an inode, so
  48  * holding xattr_sem also means that nothing but the EA block's reference
  49  * count can change. Multiple writers to the same block are synchronized
  50  * by the buffer lock.
  51  */

Regarding the "how are attributes connected" question, the link is in the other way round, the inode has a link to the extended attributes, see EXT3_XATTR_NEXT and ext3_xattr_list_entries in xattr.h and xattr.c respectively.

To recap, the attributes are linked to the inode and are fs dependent, so yes, you will lose the attributes when burning a CD rom or emailing a file.

You can add extended attributes to coreutils ls. This is based on coreutils-8.22:

***************
*** 59,62 ****
--- 59,64 ----
  #include <wchar.h>

+ #include <sys/xattr.h>
+
  #if HAVE_LANGINFO_CODESET
  # include <langinfo.h>
***************
*** 3056,3059 ****
--- 3058,3062 ----
                              : ACL_T_YES));
            any_has_acl |= f->acl_type != ACL_T_NONE;
+           any_has_acl |= listxattr(f->name, NULL, 0, XATTR_NOFOLLOW);

            if (err)
***************
*** 3811,3814 ****
--- 3814,3819 ----
    if (! any_has_acl)
      modebuf[10] = '\0';
+   else if (listxattr(f->name, NULL, 0, XATTR_NOFOLLOW) > 0)
+     modebuf[10] = '@';
    else if (f->acl_type == ACL_T_SELINUX_ONLY)
      modebuf[10] = '.';

Basically I looked in the OS X ls source to find the logic for printing the @ (the listxattr call) and hooked that into where coreutils ls puts a symbol after the permissions. The three changes are:

1. Including xattr.h
2. Set any_has_acl if any of the listings have extended attributes - this is required so that listings that don't have extended attributes have a space inserted after the permissions to line things up
3. Do the actual check by calling listxattr and conditionally setting the @ symbol - might be worth noting that they way this is written will show only the @ if there are both extended attributes and ACL

The XATTR_NOFOLLOW argument tells listxattr not to follow symlinks. That argument is used in OS X ls.