Re: [Bug-xorriso] bug with handling symbolic links?

[Thomas Schmitt]

Hi,

> Sorry to discover so much "unexpected behaviour"...

Yeah. Users are the main cause of bug reports.


> > With -dev, the old file data stay were they are and cannot
> > get reduplicated.

> So this way the symlinks-SUSP-entries could (hypothetically) be fixed by
> re-adding the files
> (i.e. extracting into hard disk file system before) into a new session (thus
> introducing somewhat more overhead)?

If the medium is not writable any more, then you need
to copy the ISO to a medium which you keep appendable
(here from /dev/sr0 to /dev/sr1)

  xorriso -as cdrecord -v blank="as_needed" -multi dev=/dev/sr1 /dev/sr0
  device=/dev/sr1

or to a data file in your local filesystem

  dd if=/dev/sr0 bs=2048 of=image.iso
  device=image.iso

The fixing rather works by adding a new directory
tree to the end of the ISO and by pointing the readers
to the superblock of that tree. The tree's data file
nodes will refer to the same data blocks as their
counterparts in the old tree.
The difference will be that the SUSP entries in the
tree part of the ISO image will be digestible for Linux. 

  xorriso -for_backup -dev "$device" -changes_pending yes

Pointing to the newest superblock is done either by
the hardware session and track list (TOC) of a sequential
medium or by overwriting block 16 of an overwritable
medium resp. an image file.

If the ISO stems from a sequential medium and was copied
to an overwritable medium or an image file, then the
new superblock will overwrite the old superblock. You will
see only a single session, the new one.
But in all other media situations you can see both
sessions, their start and size by 

  xorriso -indev "$device" -toc

Both are mountable.
The one at mount -o sbsector=0 will show the symbolic
link flaw. The one mounted by default should be flawless.


The overall media consumption resp. ISO image size will
grow by an amount which depends on the number of files,
the length of their names, and the amount of their
attributes. One may estimate the storage size in advance
by the lowest block address which is used by data file
content.
E.g.

  xorriso -indev /dev/sr2 -find / -sort_lba -exec report_lba | head -2

might yield something like

  Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
  File data lba:  0 ,       55 ,     3942 ,  8071310 , '/NBX'

The start LBA 55 tells that the superblock and tree cannot
be larger than 55 * 2048 bytes.
Your tree will be larger, i assume.


Have a nice day :)

Thomas