"Fossies" - the Fresh Open Source Software Archive

Member "xorriso-1.5.4/doc/susp_aaip_isofs_names_O_XATTR.txt" (30 Jan 2021, 6078 Bytes) of package /linux/misc/xorriso-1.5.4.pl02.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the last Fossies "Diffs" side-by-side code changes report for "susp_aaip_isofs_names_O_XATTR.txt": 1.5.2_vs_1.5.4.

    1 
    2                      libisofs internal documentation
    3                  Representing Solaris O_XATTR Attributes
    4 
    5                       - Draft - Not Yet Implemented -
    6  
    7 Solaris O_XATTR attributes are file trees which can be attached to any
    8 file object. I.e. any file can be root of a whole attribute filesystem
    9 with own attribute filesystems attached to each of its files.
   10 
   11 libisofs implements this by a separate tree of root entries for the
   12 attributes of the files. Access key is the ISO image inode number
   13 of the hosting file. This ensures that hardlinks share their attributes.
   14 If the inode number cannot be stored in Rock Ridge entry PX, then
   15 AAIP attribute isofs.in will do.
   16 
   17 The tree of attribute roots is organized in directories of at most
   18 512 sub directories. The directory names consist of uppercase hex
   19 representations of the bytes of the little endian form of the inode number.
   20 Those directories which serve as attribute roots have a suffix "a".
   21 Those which lead to the next level of the tree of roots, have no suffix.
   22 Example:
   23   inode number -> path to attribute root   
   24     0x12345678 -> 78/56/34/12a
   25         0x5678 -> 78/56a
   26 
   27 After loading an ISO image, the attribute roots might have to be re-arranged
   28 to match the eventual new inode numbering. This may mean that new attribute
   29 trees may emerge as copies of split hardlinks.
   30 >>> ??? where to implement ?
   31 
   32 All operations which care about identity of files shall take the attribute
   33 trees into account.
   34 >>> which ones ?
   35    >>> API: iso_node_cmp_ino()
   36    >>> Update isofs.pp when moving files
   37        >>> ??? which API functions move files ?
   38 
   39 The new members of the attribute root tree get produced during the
   40 preparations for image writing. If no PX serial numbers get written, then
   41 AAIP attributes isofs.in need to be written.
   42 
   43 Manipulations of O_XATTR between loading and image production are done
   44 by normal file operations on the attribute tree of the inode of the file.
   45 A xinfo function allows to record the path of a directory in the ISO image
   46 which shall replace the attribute tree of the file when the image gets
   47 written.
   48 >>> Make sure that no attribute loops emerge by xinfo-dir being boss of
   49     the file
   50 >>> ??? Enforce absolute path ${isofs.ob}/by_path/${path} ?
   51     ??? maybe within xorriso rather than libisofs ?
   52 
   53 -------------------------------------------------------------------------------
   54 xinfo functions
   55 -------------------------------------------------------------------------------
   56 
   57 >>> ??? This way ? (Or by early hand-out of inode number ?)
   58 
   59 /**
   60 
   61  >>> Not implemented yet
   62 
   63  * The function that marks data which designate a directory in the ISO image as
   64  * solaris-style O_XATTR attribute tree of an IsoNodes.
   65  * Usually an application does not call this function, but only uses it as
   66  * parameter of xinfo calls like iso_node_add_xinfo() or iso_node_get_xinfo().
   67  * The data submitted with iso_node_add_xinfo() is supposed to be an absolute
   68  * path in memory that can be disposed by free(3).
   69  *
   70  * >>> @since ?.?.?
   71  */
   72 int iso_sol_o_xattr_xinfo_func(void *data, int flag);
   73 
   74 -------------------------------------------------------------------------------
   75 AAIP variables:
   76 -------------------------------------------------------------------------------
   77 
   78 Name:
   79       >>> ??? isofs.in
   80 
   81 Purpose:
   82       Records the inode number of a file, if this is not done in a Rock Ridge
   83       PX entry (older RRIP 1.10 does not record it).
   84       This number is used to identify hardlink relations and optionally
   85       as a pointer to a directory which holds the attribute files as of
   86       Solaris-style openat(O_XATTR).
   87       The inode number is mapped to a little endian hierarchy of byte name
   88       directories
   89          0x12345678 -> 78/56/34/12a
   90              0x5678 -> 78/56a
   91       The directory names are upper case hex representations of the bytes.
   92       Those with no suffix are access branches to longer indice.
   93       Those with suffix "a" are leaf directories which hold the attribute file
   94       tree of a particular index.
   95               
   96 Format of Value:
   97       IDX_BYTES 
   98       The byte strings begin with the most significant byte.
   99 
  100 Example:
  101       Index 91337 = 0x0164C9 leading to ${ATTRIBUTE_BASE}/C9/64/01a
  102       { 1, 100, 201 }
  103 
  104 Registered:
  105       ?? ??? 201? by Thomas Schmitt for libisofs.
  106 
  107 -------------------------------------------------------------------------------
  108 
  109 Name:
  110       >>> ??? isofs.ob
  111 
  112 Purpose:
  113       Records the O_XATTR base directory where the tree of attribute roots
  114       has its root.
  115       >>> How to protect ATTRIBUTE_BASE from being populated with normal files ?
  116       >>> ??? may this directory be hidden ?
  117           --- Rather not, in order not to hamper readability on unaware systems
  118               
  119 Format of Value:
  120       ATTRIBUTE_BASE
  121       The Rock Ridge path to the attribute base directory.
  122 
  123 Example:
  124       Attribute base is "/.solaris_fsattr"
  125       { '/', '.', 's', 'o', 'l', 'a', 'r', 'i', 's', '_', 'f', 's',
  126         'a', 't', 't', 'r' }
  127 
  128 Registered:
  129       ?? ??? 201? by Thomas Schmitt for libisofs.
  130 
  131 -------------------------------------------------------------------------------
  132 
  133 Name:
  134       >>> isofs.or
  135 
  136 Purpose:
  137       Records the number of references of a O_XATTR attribute root directory.
  138       This is the number of hard links of the inode to which the directory
  139       belongs.
  140 
  141 Format of Value:
  142       REF_BYTES
  143 
  144 Example:
  145       The directory holds the attributes of a triply hardlinked file.
  146       { 3 }
  147 
  148 Registered:
  149       ?? ??? 201? by Thomas Schmitt for libisofs.
  150 
  151 -------------------------------------------------------------------------------
  152 
  153 Name:
  154       >>> isofs.pp
  155 
  156 Purpose:
  157       Records the path of the file to which an attribute directory belongs.
  158       Attribute directories are those underneath ATTRIBUTE_BASE with a name
  159       that ends by "a". E.g ${ATTRIBUTE_BASE}/78/56a
  160 
  161 Format of Value:
  162       ISO_RR_PATH
  163 
  164 Example:
  165       The directory belongs to file "/my/solaris/file"
  166       { '/', 'm', 'y', '/', 's', 'o', 'l', 'a', 'r', 'i', 's', '/', 'f',
  167         'i', 'l', 'e', }
  168 
  169 Registered:
  170       ?? ??? 201? by Thomas Schmitt for libisofs.
  171 
  172