Which program produces FreeBSD-11.0-CURRENT-amd64-*-disc1.iso ?

[Thomas Schmitt]

Hi,

the image FreeBSD-11.0-CURRENT-amd64-20151001-r288459-disc1.iso
from
  http://ftp.freebsd.org/%2Fpub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/
has some flaws or at least strange properties.

I wonder where to find the source code of the ISO 9660 producer
program.

-----------------------------------------------------------------
Problematic properties in detail:

- The root directory entry and also "/." show as "Recording Date
  and Time" the 7-byte string {165, ..., 165}, which except for the
  first byte violates ECMA-119 9.1.5. It restricts bytes 1 to 5 to
  reasonable values for month, day_of_month, hour, minute, second.
  Byte 6 shall be in the range of -48 to +52, whereas 165 as
  signed 8-byte value is -91.

- The Rock Ridge equipment of directory records of directories in
  their parent directory differs from the equipment of "." records
  in their own directory.
  E.g. "/bin" differs from "/bin/." not only by name.
  "/bin" has Rock Ridge entry TF, which gives timestamps.
    (At 2048-block 842 + offset 584 bytes)
  "/bin/." has no TF.
    (At 2048-block 844 + offset 0)
  The content of TF's Creation Time
    {115  10, 1, 21, 36, 58, 0}
  differs from the content of the ECMA-119 record fields
    {115, 10, 1, 21, 38, 24, 0}

- The Rock Ridge TF entries have Creation Time rather than
  Last Attribute Change Time.
  RRIP-1.12 says:
    "If recorded, CREATION, Creation Time, has the same meaning as in
     ISO 9660:9.5.4."
    "If recorded, ATTRIBUTES, Last Attribute Change Time, shall be
     used for the st_ctime field of POSIX:5.6.1."
  ECMA-119 (aka ISO 9660):
    "9.5.4 File Creation Date and Time (BP 11 to 27)
     This field shall specify the date and the time of the day at
     which the information in the file was created."
  So for recording ctime, the FreeBSD ISO uses the wrong TF field.

- Some files have Rock Ridge NM fields, some don't.
  The NM field records the case sensitive long name of the file.
  Having none makes the file name prone to mapping when it gets
  shown by reader software. Typical mappings are:
  - Removal of trailing ".;1" or ";1".
  - Presentation as lowercase characters.
  Missing are the NM fields of the directories in
    /usr/share/i18n/csmapper
      (At 2048-block 323995)
    /usr/share/i18n/esdb
      (At 2048-block 338174)
  and of the directory "C" in
    /usr/share/nls
      (At 2048-block 353273)
  The regular files in the same directories do have NM.


Have a nice day :)

Thomas