"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