libburnia/web
2
0
Code Wiki

Thomas Schmitt 2020-07-07 14:31:55 +00:00
parent 903a3b8bb0
commit 347eabdd44
1 changed files with 739 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

739
AAIP.md Normal file

@ -0,0 +1,739 @@
Coordinated with SUSP 1.12 and RRIP 1.12 this specification
defines a matching extension for storing ACLs and xattr with the file
objects in the ISO image. (See `man 5 acl` , `man 5 attr`)
ISO 9660 aka ECMA-119 describes a non-POSIX hierachical filesystem
suitable mainly for directories and plain data files. Within that
specification there is some extension space for each file object,
the System Use Area. SUSP specifies a framework for using this area
as storage for add-on data. RRIP specifies within that framework
how to represent the classical POSIX file attributes (ownership,
permissions), special file types (device nodes, symbolic links)
and long file names. Regrettably it does not cover ACL and xattr.
This gap shall be closed by AAIP.
Fundamental idea is to use the same field format as the RRIP field
SL which is able to represent target paths of symbolic links.
There is nearly no limit for the length of a single component or
for the number of components but only the overall size limit of an
ISO 9660 image: 8 TB.
SL paths and AAIP attribute lists are isomorphic via the representation
```
/ name1 / value1 / name2 / value2 / name3 / value3 / ...
```
The format of SL allows any byte value in the components,
including 0-bytes and "/"-characters.
This choice gives hope that existing Rock Ridge readers can re-use
their SL parser code for an AAIP field parser.
A binary representation of ACLs is defined in order to make this kind
of attributes as compact as possible. Within that ACL definition
there is an optional translation table for names versus id numbers
of users and groups.
The following specification is implemented since `libisofs-0.6.18`.
Its predecessor AAIP-1.0 is implemented since `libisofs-0.6.14` and will
stay readable by `libisofs-0.6.18` and later.
TRANSLATE entries are neither produced nor interpreted yet.
```
Arbitrary Attribute Interchange Protocol
Version 2.0
Mar 18 2009
Interchange of Persistent File Attributes
by Thomas Schmitt - mailto:scdbackup@gmx.net
Libburnia project - mailto:libburn-hackers@pykix.org
AAIP is intended as companion of the Rock Ridge Interchange Protocol RRIP
which under the general design of System Use Sharing Protocol SUSP extends
ISO 9660 aka ECMA-119 filesystem semantics to match POSIX needs.
Goal is to have for each file an arbitrary number of attributes which consist
of two components (Name and Value) of arbitrary length and to have a compact
representation of ACLs.
This document describes a SUSP entry with Signature Word "AL" which collides
neither with SUSP 1.12 nor with RRIP 1.12. The AL entry has been designed
to be as similar to the RRIP entry SL as possible.
The presence of AAIP shall be announced by a particular ER entry.
Since the size of a SUSP entry is limited to 255, multiple entries may be
needed to describe one component. The CE mechanism of SUSP shall be used to
address enough storage if needed.
AL entries and the ER entry of AAIP shall only be present if the ER entry
of RRIP is present.
-------------------------------------------------------------------------------
System Entries Provided by this Specification
* AL
Description of the "AL" System Use Entry
The entry has exactly the same layout as RRIP entry SL. One has to expect
more data bytes than with SL, though, and any of the 256 possible byte values.
The reader shall be prepared to detect and handle oversized data.
One or more AL entries form the Attribute List of a file object with
an even number of components. Each two consequtive components form a pair of
Name and Value.
The empty name indicates that the value is a compact representation of ACLs.
Names must not contain byte value 0x00. Names which begin by bytes 0x01 to 0x1f
represent names in particular namespaces. See below: Namespaces.
The meaning of any other names or name parts is not specified by this document.
All AL entries except the last one shall have the CONTINUE flag set. An AL
entry with CONTINUE set to 0 indicates the end of the Attribute List.
The format of the AL System Use Field is as follows:
[1] "BP 1 to BP 2 - Signature Word" shall be (41)(4C) ("AL").
[2] "BP 3 - Length" shall specify as an 8-bit number the length in bytes of
the AL entry recorded according to ISO 9660:7.1.1.
[3] "BP 4 - System Use Entry Version" shall be 1 as in ISO 9660:7.1.1.
[4] "BP 5 - Flags" shall contain bit field flags numbered 0 to 7 starting
with the least significant bit as follows:
0 CONTINUE This AL entry continues in the next AL entry.
All other bits shall be set to 0.
[5] "BP 6 to Length - Component Area" shall contain Component Records
as described below.
| 'A' | 'L' | LENGTH | 1 | FLAGS | COMPONENT AREA |
Within AL entries each component (Name or Value) shall be recorded as one
or more component records. If a component does not fit into the remaining
space of an AL entry then it shall be continued in following AL entries.
All Component Records of a component except the last one shall have the
CONTINUE flag set. A Component Record with CONTINUE set to 0 indicates the end
of the component. An eventually following Component Record starts the next
component.
-------------------------------------------------------------------------------
The Component Record format is identical to the one of the SL entry.
The complete form of the following summary can be found in RRIP 1.12 "4.1.3.1".
In case of discrepancies, RRIP 1.12 is the decisive specification. Please
inform the author of this document if you find such a discrepancy.
Component Records shall be recorded contiguously within each Component Area,
starting in the first byte of the Component Area. The last Component Record
in the Component Area of an AL System Use Entry may be continued in the
Component Area of the next recorded AL System Use Entry in the same
System Use Area.
Each Component Record shall have the following format:
[A] "BP 1 - Component Flags" shall contain bit field flags numbered 0 to 7,
starting with the least significant bit, as follows:
0 CONTINUE This Component Record continues in the next
AL Component Record.
all others are RESERVED and shall be 0.
[B] "BP 2 - Component Length (LEN_CP)" shall specify as an 8-bit number the
number of component bytes in the Component Record. This length shall not
include the first two bytes of the Component Record.
If any of the bit positions 1-3 is set, the value of this field shall be
set to ZERO and no Component Content shall be recorded.
This field shall be recorded according to ISO 9660 Format section 7.1.1.
[C] "BP 3 to 2 + LEN_CP - Component Content" shall contain the component
bytes in the Component Record.
| COMPONENT FLAGS | LEN_CP | COMPONENT BYTES |
Example: Two pairs of "name"="long...content" and "one"="more" encoded as
two AL entries
Field 1 contains the Component Record of Name and one Component Record of
Value :
{ 'A', 'L', 255, 1, 1,
0, 4, 'n', 'a', 'm', 'e',
1, 255, 'l', 'o', 'n', 'g', ... 238 more bytes, 13 go to next AL ... }
Field 2 contains the rest of "long...content" and the complete second pair.
It marks the end of the Attribute List :
{ 'A', 'L', 38, 1, 0,
... 13 remaining bytes of the Component Record in first entry ...
0, 7, 'c', 'o', 'n', 't', 'e', 'n', 't',
0, 3, 'o', 'n', 'e',
0, 4, 'm', 'o', 'r', 'e' }
-------------------------------------------------------------------------------
Namespaces
AAIP provides a short notation for namespaces which uses a single non-printable
byte at the start of the name.
Reserved start bytes of names are
0x01 to 0x1F
The names of extended file attributes are traditionally organized in
namespaces, which get expressed as first part of an attribute name up to a
period "." character. It is also tradition that names are printable text,
single words and especially contain no 0-bytes.
AAIP does not enforce the use of any namespace but it urges that names in the
following registered namespaces are used according to traditions.
The namespaces "system." and "user." are available with many file system
types. "system." is file system dependent and often restricted in the
choice of names. "user." is portable and allows the application to choose
about any name.
Namespace "isofs." is defined for internal use of AAIP enhanced ISO 9660
file systems. Names in this namespace should be registered at libburnia-project.org.
Further namespaces may be registered at libburnia-project.org.
The reserved start bytes of names have the following meaning
0x01 escape reserved character at start of name
0x02 namespace "system."
0x03 namespace "user."
0x04 namespace "isofs."
0x05 namespace "trusted."
0x06 namespace "security."
0x07 to 0x1F shall not be used yet.
Examples:
Name "user.abc" with and without short notation. Both is allowed.
0, 4, 0x03, 'a', 'b', 'c'
0 8, 'u', 's', 'e', 'r', '.', 'a', 'b', 'c'
Name "\003abc" (if really desired)
0, 5, 0x01, 0x03, 'a', 'b', 'c'
-------------------------------------------------------------------------------
Specification of binary ACL representation as special Arbitrary Attribute
The Name component of a binary ACL shall be of length 0.
The Value shall be an arbitrary number of ACL Entries:
[a] "BP 1 - Entry Flags" shall contain bit field flags numbered 0 to 7,
starting with the least significant bit, as follows:
0 EXEC indicates that this entry grants execute permission
1 WRITE write permission
2 READ read permission
3 QUALIFIER indicates that one or more Qualifier Records follow
4 - 7 TYPE
shall contain the tag type of the ACL entry as four bit code:
0 TRANSLATE Entry for a global map of name to numeric id
Qualifier is a record of number and text
1 ACL_USER_OBJ Permissions of owning user (as of PX entry)
3 ACL_GROUP_OBJ Permissions of owning group (as of PX entry)
5 ACL_MASK Restricts 10, 3, and 12 via logical AND
6 ACL_OTHER Permissions of non-listed, non-owning users
8 SWITCH_MARK Switch from "access" ACL to "default" ACL
10 ACL_USER_N Permissions of arbitrary user. Qualifier is
the numeric user id (max. 4 bytes).
12 ACL_GROUP_N Permissions of arbitrary group. Qualifier is
the numeric group id (max. 4 bytes).
15 FUTURE_VERSION Will indicate that this document
does not apply to the entry.
The other values are reserved. Readers shall ignore them if
they are not aware of updates of this document which would
assign a meaning to them.
The entries must match the permission bits of the PX entry. This shall obey the
rule that ACL_USER_OBJ must match S_IRWXU, ACL_OTHER must match S_IRWXO,
ACL_MASK - if present - must match S_IRWXG, else ACL_GROUP_OBJ must match
S_IRWXG. If there is ACL_USER_N or ACL_GROUP_N there must also be ACL_MASK.
A numeric qualifier is a binary number of variable length up to 4 bytes. The
Most Significant Byte comes first. The number shall be the "POSIX File User ID"
or "POSIX File Group ID" as also used in RRIP PX entries. The ids of owning
user and owning group shall be taken from the PX entry of the file object.
Optional TRANSLATE entries may associate user or group names with numeric
ids to allow the reading system to remap the numeric ids. See below.
The writer is not obliged to write them and the reader is not obliged to
interpret them.
The ACL entries belong to the "access" ACL of a file object. An optional
SWITCH_MARK entry may direct further entries to the "default" ACL which
is defined for directory objects. The EXEC bit of SWITCH_MARK shall be 1.
The bits for WRITE, READ, QUALIFIER shall be 0.
An eventually needed qualifier is stored in one or more Qualifier Records.
[b] "BP 2 - Qualifier Record Head" shall be present only if QUALIFIER is set
to 1. It shall give the number of Qualifier Bytes and eventually
indicate that the qualifier continues in a Qualifier Record which comes
imediately after this record.
0 to 127 Q_LENGTH, the qualifier is complete by this record
128 to 255 Q_LENGTH+128, the qualifier is continued by next record
So a Qualifier Record can contain at most 127 Qualifier Bytes.
This field shall be recorded according to ISO 9660 Format section 7.1.1.
[c] "BP 3 to BP 2 + Q_LENGTH - Qualifier Bytes" shall be present only if
QUALIFIER is set to 1 and hold the announced number of bytes of the
user or group name.
| ENTRY FLAGS [ | QUALIFIER HEAD | QUALIFIER BYTES | ]
Example: From man 5 acl: u::rw-,u:lisa:rw-,g::r--,g:toolies:rw-,m::r--,o::r--
"lisa" has user number 123, "toolies" has group number 65534
{ 'A', 'L', 20, 1, 0,
0, 0,
0, 11, 0x16,
0xAE, 1, 123,
0x34,
0xCE, 2, 255, 254,
0x54,
0x64 }
Example: "Access" ACL and "default" ACL (0x81 is the switch mark)
u::rwx,g::r-x,o::r-x, du::rwx,dg::r-x,dm::rwx,do::r-x,du:lisa:rwx
{ 'A', 'L', 20, 1, 0,
0, 0,
0, 11, 0x17, 0x35, 0x65,
0x81,
0x17, 0x35, 0x57, 0x65,
0xA7, 1, 123 }
-------------------------------------------------------------------------------
Association of Names and Numeric Identifiers
The entry flag value 0x08 TRANSLATE is not a ACL entry of the hosting object
but rather a global hint about the relation of roles, names and numeric ids.
If it is recorded at all, then it shall be recorded with the first Directory
Entry of the volume's root directory. According to the description of SUSP
entry ER, this has to be "dot" or (00). Other than with ER, a TRANSLATE entry
may not appear in the root of directory sub trees.
An interested reader shall examine the Arbitrary Attributes of this Directory
Entry in order to collect a translation table.
The advised translation is: PX or AL Id number -> name -> local id number.
The Qualifier Bytes of a TRANSLATE entry shall have the following format:
[i] "BP 0 - Role" shall tell whether it is about a user name (role 0) or
a group name (role 1). Other values are not allowed.
[ii] "BP 1 to BP 8 - Numeric Id" shall hold the 32 bit POSIX Id number of the
entry. This field shall be recorded according to ISO 9660:7.3.3.
[iii] "BP 9 to End Of Qualifier - Name" shall hold the name bytes of this
entry.
| ROLE | NUMERIC ID | NAME |
Example: User id number 123 gets associated with user name "lisa"
0x08, 13, 0, 123,0,0,0, 0,0,0,123, 'l', 'i', 's', 'a',
Example: A very long qualifier naming "His_Excellency_..._the_Boss" as user #1.
This needs two qualifier records.
0x08, 255, 0, 1,0,0,0, 0,0,0,1,
'H', 'i', 's', '_', 'E', 'x', 'c', 'e', 'l', 'e',
... 108 more bytes ...
8, 't', 'h', 'e', '_', 'B', 'o', 's', 's',
-------------------------------------------------------------------------------
Specification of the ER System Use Entry Values for AAIP:
This ER system entry shall only be present if the ER entry of RRIP is present.
To be compliant with SUSP-1.12, this ER entry must be present if AL entries
are present, and ES entries have to mark RRIP and AAIP entries.
If for some reason compliance with SUSP-1.10 is intended, then this ER entry
and the ES entries must not be present, although SUSP-1.10 would allow ER.
(See below: Compatibility considerations.)
The Extension Version number for this version of AAIP shall be 1.
The Extension Identifier field shall be "AAIP_0200" with Identifier Length 9.
The mandatory content form of the Extension Descriptor is
"AL PROVIDES VIA AAIP 2.0 SUPPORT FOR ARBITRARY FILE ATTRIBUTES IN ISO 9660 IMAGES"
The Description Length is 81.
The recommended content of the Extension Source is
"PLEASE CONTACT THE LIBBURNIA PROJECT VIA LIBBURNIA-PROJECT.ORG".
The corresponding Source Length is 62.
-------------------------------------------------------------------------------
Compatibility Considerations
This extension is supposed not to disturb any reader system which complies
to SUSP-1.10:
"6.2 Requirements for a Receiving System
[...]
Any System Use Field which the receiving system does not recognize
is to be ignored and skipped."
SUSP-1.12 extends this prescription by:
"Any System Use Entry, with the exception of the set of System Use Entries
defined in this document, following an "ES" System Use Entry that indicates
an extension specification which the receiving system does not recognize
shall be ignored and skipped."
According to SUSP-1.12 the ER entry is mandatory for a conformant extension.
It also prescribes that in the case that ER entries of RRIP and AAIP are
present, then ES entries shall be used to separate RRIP entries from AAIP
entries.
SUSP-1.12 frowns on extensions which are not announced by ER. Nevertheless
is does not totally outrule them.
SUSP-1.10 does not specify ES entries at all and does not demand to announce
extension entries by an ER entry. But if there is the AAIP ER then there
must be ES at the appropriate places. Else the format would explicitely
violate SUSP-1.12.
-------------------------------------------------------------------------------
Model Relations:
Attribute List ------------- [1:0..1] ------------- ACL
[1:0..n] [1:0..n]
Arbitrary Attribute ( [1:0..1] ACL ) Entry
[1:2..2n] [1:0..1]
Component ( [1..m:1..n] AL Field ) Qualifier
[1:1..n] << one of >>
Component Record / \
[1..m:1..n] Translation Entry , Numeric Id
AL Field | |
[1:1..n] [1:1]
\ /
Qualifier Record
-------------------------------------------------------------------------------
Revoked drafts:
The following outdated versions may be interpreted at read time but they
shall not be written any more.
AAIP-1.0
Previous versions up to AAIP 1.0 used field signature "AA" rather than "AL".
This nearly collides with "Apple ISO 9660 Extensions". The Apple "AA" field of
version 1 has a length of 7, whereas the shortest first AAIP field "AA" had
length 9.
Beginning with AAIP 2.0, the field name has been changed to "AL".
If a reader interprets old AAIP "AA" fields, then it must take precautions to
distinguish them from Apple "AA" fields. But it is well compliant with AAIP 2.0
to just ignore any kind of "AA" fields.
AAIP 1.0 had ER signature "AAIP_0100".
AAIP-0.2
AAIP 0.2 with ER signature "AAIP_0002" provided means to announce and use a
different signature than "AA". This was revoked because ES entries serve the
purpose to distinguish AAIP entries from eventual "AA" entries of any other
extension.
Regrettably no reader (kernel) was found which neatly interprets ES. Many do
not even recognize the RRIP-1.12 ER signatures "IEEE_P1282", "IEEE_1282".
AAIP 0.2 defined two ACL types which did not make it into AAIP 1.0
2 ACL_USER of arbitrary user, with name as qualifier
4 ACL_GROUP of arbitrary group, with name as qualifier
Their job was transferred to ACL_USER_N and ACL_GROUP_N which have numeric
qualifiers.
AAIP-0.0
There was a draft AAIP 0.0 with ER signature "AAIP_2008A". It did not resemble
the existing entry SL and was never implemented.
-------------------------------------------------------------------------------
References:
ECMA-119 aka ISO 9660
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf
SUSP 1.12 (entries CE , PD , SP , ST , ER , ES)
ftp://ftp.ymi.com/pub/rockridge/susp112.ps
RRIP 1.12 (entries PX , PN , SL , NM , CL , PL , RE , TF , SF , obsolete: RR)
ftp://ftp.ymi.com/pub/rockridge/rrip112.ps
Apple ISO 9660 Extensions (entries AA and BA)
http://developer.apple.com/technotes/fl/fl_36.html
Amiga AS entry
http://www.estamos.de/makecd/Rock_Ridge_Amiga_Specific
zisofs entry ZF (prepared by zisofs-tools, written by mkisofs)
http://freshmeat.net/projects/zisofs-tools/
http://libburnia-project.org/wiki/zisofs
Program mkisofs emits entry XA
ftp://ftp.berlios.de/pub/cdrecord/alpha
-------------------------------------------------------------------------------
```
This text is part of the libisofs release as `doc/susp_aaip_2_0.txt` .
-------
Libburnia maintains a directory where names from namespace "isofs." may be registered.
Interested application programmers are invited to submit own names and their description.
```
Arbitrary Attribute Interchange Protocol
Interchange of Persistent File Attributes
Directory of Namespace "isofs."
by Thomas Schmitt - mailto:scdbackup@gmx.net
Libburnia project - mailto:libburn-hackers@pykix.org
The following names are defined for AAIP namespace "isofs." as mentioned in
specification of AAIP. Unless explicitly stated otherwise, numbers with
names like *_LEN are 8 bit unsigned integers, those with *_BYTES are 32 bit
unsigned integers.
-------------------------------------------------------------------------------
Name:
isofs.ca
Purpose:
Records the range of checksummed image data (START, END), the number
of checksum items (COUNT), the number of bytes in a single checksum item
(SIZE), and the name of the checksum algorithm (CHECKSUM_TYPE).
END is also the block address of the start of the checksum recording
area in the image.
See also isofs.cx .
This attribute shall be attached to the root directory entry
and be global for the whole image.
Format of Value:
START_LEN | START_BYTES | END_LEN | END_BYTES |
COUNT_LEN | COUNT_BYTES | SIZE_LEN | SIZE_BYTES | CHECKSUM_TYPE
Each number is encoded as _LEN byte and _BYTES value string.
The _LEN fields comply to ISO 9660 Format section 7.1.1.
The byte strings START_BYTES, END_BYTES, COUNT_BYTES, SIZE_BYTES begin
with the most significant byte. Leading zero bytes are allowed.
CHECKSUM_TYPE consists of the bytes after
START_LEN + END_LEN + COUNT_LEN + SIZE_LEN + 4.
It shall be a string of printable characters without terminating 0-byte.
Type names shall be registered here.
For now there is:
"MD5" 128 bit message digest, see RFC 1321, see man md5sum
Example:
LBA range 32 to 1000000 , 520 checksums recorded, MD5
{ 1, 32,
3, 15, 66, 64,
2, 2, 8,
1, 16,
'M', 'D', '5' }
or
{ 4, 0, 0, 0, 32,
4, 0, 15, 66, 64,
4, 0, 0, 2, 8,
1, 16,
'M', 'D', '5' }
Registered:
16 Jul 2009 by Thomas Schmitt for libisofs.
-------------------------------------------------------------------------------
Name:
isofs.cs
Purpose:
Records the name of the character set that was used as output character
set when writing the RRIP name tree of the ISO 9660 image. It shall be
suitable as parameter for function iconv_open(3).
This attribute shall be attached to the root directory entry and be
global for the whole image.
Format of Value:
Shall hold the character set name without terminating 0-byte.
Example:
{ 'I', 'S', 'O', '-', '8', '8', '5', '9' , '-', '1' }
Registered:
18 Mar 2009 by Thomas Schmitt for libisofs.
-------------------------------------------------------------------------------
Name:
isofs.cx
Purpose:
Records the index of the file's checksum in the checksum area at the
end of the image. The byte address of the checksum is
checksum_area_lba * 2048 + isofs.cx * checksum_size
Default checksum algorithm is MD5 with a size of 16 byte.
See also isofs.ca .
Format of Value:
A byte string which begins with the most significant byte.
Example:
Index 123456
{ 1, 226, 64 }
Registered:
16 Jul 2009 by Thomas Schmitt for libisofs.
-------------------------------------------------------------------------------
Name:
isofs.di
Purpose:
Records .st_dev and .st_ino of struct stat of the file source in the
local filesystem. See man 2 stat.
Both values may be unsigned integers up to 255 bytes.
Format of Value:
DEV_LEN | DEV_BYTES | INO_LEN | INO_BYTES
The _LEN fields comply to ISO 9660 Format section 7.1.1.
The byte strings begin with the most significant byte.
Example:
Device number 2001, inode number 176343
{ 2, 7, 209,
3, 2, 176, 215 }
Registered:
17 Feb 2009 by Thomas Schmitt for xorriso.
-------------------------------------------------------------------------------
Name:
isofs.hb
Purpose:
Records the IsoHfsplusBlessings blessing of a IsoNode as defined
in libisofs.h. At image load time, this info may be converted back
into a relation between IsoImage and IsoNode so that it is available for
the HFS+ writer when a new ISO 9660 / HFS+ image gets produced.
Format of Value:
BLESSING
This is a single byte out of {'p', 'i', 's', '9', 'x'} for
ISO_HFSPLUS_BLESS_PPC_BOOTDIR, ISO_HFSPLUS_BLESS_INTEL_BOOTFILE,
ISO_HFSPLUS_BLESS_SHOWFOLDER, ISO_HFSPLUS_BLESS_OS9_FOLDER,
ISO_HFSPLUS_BLESS_OSX_FOLDER.
Example:
{ 'p' }
Registered:
07 Jun 2012 by Thomas Schmitt for xorriso.
-------------------------------------------------------------------------------
Name:
isofs.hx
Purpose:
Records the iso_hfsplus_xinfo_data information as defined in libisofs.h.
At image load time, this info may be converted back into an xinfo
attachment for iso_hfsplus_xinfo_func so that it is available for
the HFS+ writer when a new ISO 9660 / HFS+ image gets produced.
Format of Value:
VERSION_LEN | VERSION | CREATOR | TYPE
VERSION_LEN complies to ISO 9660 Format section 7.1.1.
The byte string VERSION begins with the most significant byte.
VERSION == 0 is the only one that is currently defined. It assures the
existence of 4 bytes CREATOR and 4 bytes TYPE.
Higher versions will keep these 8 bytes and possibly add new ones.
Example:
{ 1, 0, 'Y', 'Y', 'D', 'N', 'T', 'E', 'X', 'T' }
Registered:
07 Jun 2012 by Thomas Schmitt for xorriso.
-------------------------------------------------------------------------------
Name:
isofs.nt
Purpose:
Records the name truncation mode and the truncation length for Rock Ridge
names. See iso_image_set_truncate_mode() in libisofs.h.
This attribute shall be attached to the root directory entry and be
global for the whole image.
Format of Value:
MODE_LEN | MODE_BYTES | LENGTH_LEN | LENGTH_BYTES
Example:
{ 1, 1, 1, 255 }
Registered:
24 Sep 2015 by Thomas Schmitt for libisofs.
-------------------------------------------------------------------------------
Name:
isofs.st
Purpose:
Records a time point at least 1 second before any nodes were added to a
freshly loaded or created ISO image. Nodes in the image which have
younger timestamps are suspect to have changed their content during
image production and might bear inconsistent content.
The RRIP timestamps have a blind second during which a change after
node registration would not be recognizable for incremental backups
which are based in "isofs.di" rather than on content comparison.
This attribute shall be attached to the root directory entry
and be global for the whole image.
Format of Value:
Shall hold UTC seconds since 1970 as decimal number string without
terminating 0-byte.
Example:
{ '1', '2', '3', '8', '7', '4', '2', '2', '9', '6' }
Registered:
03 Apr 2009 by Thomas Schmitt for xorriso.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
This text is under
Copyright (c) 2009 - 2011 Thomas Schmitt <scdbackup@gmx.net>
It shall only be modified in sync with libisofs and other software which
makes use of AAIP. Please mail change requests to mailing list
<libburn-hackers@pykix.org> or to the copyright holder in private.
Only if you cannot reach the copyright holder for at least one month it is
permissible to modify this text under the same license as the affected
copy of libisofs.
If you do so, you commit yourself to taking reasonable effort to stay in
sync with the other interested users of this text.
```
This text is part of the libisofs release as `doc/susp_aaip_isofs_names.txt` .