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

[Joerg Meyer]

Hi Thomas,

OK, I can confirm that going "via -dev ..." with your latest 1.3.9 tarball 

        dd if=/dev/sr0 bs=2048 of=gentoo-201501-1.3.8.iso
        cp --reflink=always -a gentoo-201501-1.3.8.iso gentoo-201501-1.3.9.iso
        xorriso -for_backup -dev gentoo-201501-1.3.9.iso -changes_pending yes

leads to a isovfy-error-free multisession isofs.
(Here --reflink=always produces a "copy" in BTRFS which only stores blocks that 
are modified in a new physical location on disk.) 

I think the multisession overhead of 68,747,264 bytes
        # ls -l
        -rw-r--r-- 1 root root 4390518784 Mar  8 13:30 
gentoo-201501-root_card_add-1.3.8.iso
        -rw-r--r-- 1 root root 4459266048 Mar  8 13:46 
gentoo-201501-root_card_add-1.3.9.iso
is about two thirds of what to expect from
        Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
        File data lba:  0 ,    51709 ,        0 ,        0 , 
'/@gentoo-root.20150117-ext4_up_to_date/boot/.keep'
(51,709 * 2048 = 105,900,032)

Thanks again & best wishes,
Jörg.


On 07 Mar 2015, at 23:13, Thomas Schmitt <address@hidden> wrote:

> 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
>