Comment les attributs étendus sont-ils stockés et préservés?


11

J'ai une petite question sur les attributs de fichier étendus. Supposons que j'étiquette mes fichiers avec des métadonnées dans des attributs étendus (par exemple pour tenir compte de l'intégrité - mais cela n'a pas d'importance pour ma question). Les questions qui se posent maintenant:

  • Où sont stockés ces attributs? Sûrement pas dans l'inode, je suppose, mais dans quel endroit - ou mieux: la structure?
  • Comment ces attributs sont-ils connectés à un fichier? Existe-t-il un lien entre la structure d'attribut et l'inode?
  • Que se passe-t-il lors de la copie / du déplacement de fichiers? Je viens de le tester, lors du déplacement d'un fichier, le fichier reste ses attributs. Lors de sa copie, la copie n'a pas d'attributs. Je suppose donc que lors de la gravure sur CD ou de l'envoi du fichier par e-mail, il perdra également ses attributs?

Réponses:


10

La réponse à votre question est spécifique au système de fichiers. Pour ext3, par exemple, consultez fs / ext3 / xattr.c , il contient la description suivante:

  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  */

En ce qui concerne la question "comment les attributs sont-ils connectés", le lien est inversé , l'inode a un lien vers les attributs étendus, voir EXT3_XATTR_NEXTet ext3_xattr_list_entriesdans xattr.h et xattr.c respectivement.

Pour récapituler, les attributs sont liés à l'inode et dépendent de fs, donc oui, vous perdrez les attributs lors de la gravure d'un CD-ROM ou de l'envoi d'un fichier par e-mail.


6
Un détail mineur qui n'est pas répondu ici: Vous pouvez conserver les attributs lors de la copie (bien sûr, vous devez copier sur un système de fichiers avec support xattr). cp a une option "--preserve = xattr"
Marcel Stimberg
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.