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: Fri, 09 May 2014 18:42:04 +0200

 >  -rw-r--r--  1 dbus  dbus  4294965248 May  6 15:30 large_file
 >  -rw-r--r--  1 dbus  dbus  4294965248 May  6 15:30 large_file
 
 This is a different bug. ISO 9660 level 3 allows to store files
 larger than 4 GiB - 1. This is done by several directory entries
 with the same name marking a byte interval ("extent") of the
 overall file.
 There is no global indication in a filesystem for ISO 9660 level 3.
 You recognize it by encountering multi-extent files. 
 
 The real situation as reported by 
   xorriso -find /my/large_file -exec report_lba
 is that the first extent starts at block 56 and has 2097151 blocks.
 The second extent starts at block 2097207 and has 16802 blocks.
 The combined file size is  4329375744 bytes.
 
 
 >  The norrip case works as expected:
 >   -r-xr-xr-x  1 root  wheel  34410496 May  6 15:30 large_file
 
 It does not, i fear. It just shows a different skewed projection
 of the large file:  4329375744 - 4294965248 = 34410496.
 I.e. we see the second extent with the remaining bytes of the
 file above byte address 4 GiB - 2048.
 (You can combine one file from with RRIP and the file of -norrip
  to get the original large file. Easier would be to let xorriso
  extract it to hard disk.)
 
 When i assessed the problem in FreeBSD 2 years ago, i noticed
 a 1:1 relation between iso_node and extent. It would have to
 become 1:n, or multi-extent files would have to be handled
 as reason for a well contained error. (Not easy to imagine how
 the latter shall work consistently.)
 
 I plan to look for a solution.
 But that change will be a fat patch, i guess, because it will
 include an adjustment of the object relationship graph in cd9660.
 
 Between this quite clear PR 48787 and the PR for large files
 i plan to post a PR for scaling down cd9660 inode numbers by a
 factor of 32. See ls -i and its 32-bit rolled over inode number
 display with the test image.
 
 But i first want to gain more experience about NetBSD cooperation
 by this PR 48787. Be invited to teach me how to make it convenient
 for those who decide about commits.
 
 (Also i have found one spot in libisofs which needs closer
  inspection in respect to 64 bit ino_t. Pot, kettle, black.)