Re: kern/48787

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

The following reply was made to PR kern/48787; it has been noted by GNATS.

From: "Thomas Schmitt" <scdbackup%gmx.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48787
Date: Tue, 06 May 2014 18:43:26 +0200

 Martin Husemann wrote:
 > Is it possible to create a failing image via some
 > simple script and makefs -f cd9660 (or other base system tools)?
 
 I don't think so.
 
 makefs(8) would need an option to load the directory tree of
 an existing image, to modify this tree model, and to write
 the new tree plus the data blocks of newly added files to
 the end of the exiting image. Finally it would have to overwrite
 the "superblock" at offset 0 (PVD at block 16) in order to
 point mount(8) resp. cd9660_vfsops.c:iso_mountfs() to the new
 root directory.
 I don't see such options or capabilities in makefs(8).
 
 growisofs operates mkisofs with options -M -C for this purpose.
 My own program xorriso operates via libisoburn and libisofs.
 
 I uploaded heavily zero-containing
 
    http://scdbackup.webframe.org/large.iso.bz2
 
 Only 4470 bytes, MD5 7d78dc3efaec8ea3f1801335329f410d.
 It inflates to 4,329,897,984 bytes.
 
 Submitted to my virtual NetBSD via qemu -cdrom, it causes with
 kernel 6.1.3
 
   netbsd# mount -t cd9660 /dev/cd0a /mnt
   netbsd# ls -l /mnt
   -r-xr-xr-x  1 root  wheel  0 Jan  1  1970 /mnt
 
 Whereas with my patched 6.99.40
 
   netbsd# mount -t cd9660 /dev/cd0a /mnt
   netbsd# ls -l /mnt
   total 4
   drwxr-xr-x  1 thomas  dbus  2048 May  6 15:30 my
   -rw-r--r--  1 thomas  dbus     6 May  6 15:34 small_file
 
 -------------------------------------------------------------
 The image was created by
 
   # First session with enough input to surpass 4 GiB
   dd if=/dev/zero bs=2048 count=1 seek=2113952 of=large_file
   xorriso -outdev large.iso -blank as_needed \
           -map large_file /my/large_file
   rm large_file
 
   # Second session
   echo "hello" >small_file
   xorriso -dev large.iso \
           -map small_file /small_file
   rm small_file
 
   # Inspecting situation
   xorriso -indev large.iso -toc -find / -exec lsdl --
 
 reports:
   ...
   TOC layout   : Idx ,  sbsector ,       Size , Volume Id
   ISO session  :   1 ,        32 ,   2113977s , ISOIMAGE
   ISO session  :   2 ,   2114016 ,        25s , ISOIMAGE
   Media summary: 2 sessions, 2114002 data blocks, 4129m data, 5158m free
   Media nwa    : 2114048s
   drwxr-xr-x    1 0        0               0 May  6 17:31 '/'
   drwxr-xr-x    1 1000     1000            0 May  6 17:30 '/my'
   -rw-r--r--    1 1000     1000     4329375744 May  6 17:30 '/my/large_file'
   -rw-r--r--    1 1000     1000            6 May  6 17:34 '/small_file'
 
 (After remedy, look into directory ./my to see a problem
  with files larger than 4 GiB - 1. ISO 9660 level 3 allows
  multiple extents. cd9660 neither rejects nor does it work
  correctly:
   netbsd# ls -l /mnt/my
   total 16777208
   -rw-r--r--  1 thomas  dbus  4294965248 May  6 15:30 large_file
   -rw-r--r--  1 thomas  dbus  4294965248 May  6 15:30 large_file
 
  NetBSD is not alone with these bugs. See:
    http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038552.html
    http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038570.html
  I was quite clueless, then. This time i dug with more success.
 )