Duplicate inodes in 5.4-RELEASE-i386-disc1.iso

[John Baldwin]

On Thursday 23 June 2005 11:45 am, Dag-Erling Smørgrav wrote:
> Scott Long <scottl at samsco.org> writes:
> > Gregg Cooper wrote:
> > > 15005 -r--r--r--  2 root  wheel      0 May  8 03:05 dumpdates
> > > 15005 -r--r--r--  2 root  wheel    142 May  8 03:05 fbtab
> > > 83266 -r--r--r--  2 root  wheel     0 May  8 03:01 locale
> > > 83266 -r--r--r--  2 root  wheel    31 May  8 03:01 mm.tmac
> > > 83269 -r--r--r--  2 root  wheel     0 May  8 03:01 se_locale
> > > 83269 -r--r--r--  2 root  wheel    97 May  8 03:01 se_ms.cov
> > > 99056 -r--r--r--  2 root  wheel     0 May  8 03:05 utmp
> > > 99056 -r--r--r--  2 root  wheel  18425 May  8 03:04 Makefile.dist
> >
> > Maybe it's a bug in mkisofs?
>
> ISO 9660 filesystems donn't have inode numbers.  The cd9660 code fakes
> them based on the location of each file's contents.  This model breaks
> down for empty files, which have no contents and thus no meaningful
> location.  Apparently, mkisofs simply keeps track of the last extent
> written and uses that for the location of the next file regardless of
> whether it actually has any contents, so empty files get the same
> inode number as the previous non-empty file.
>
> The attached patch will make mkisofs assign the lowest valid non-zero
> address to all empty files.  They will therefore appear to be hard
> links to eachother, but not to random non-empty files.

Even if mkisofs is patched this change isn't a bug in mkisofs.  It's really a 
bug in our iso9660 filesystem. :(

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org