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

[Gregg Cooper]

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.
>
>DES
>  
>
Scott: Thanks for the Makefile snippet.

DES: So fast - thanks! You provided a solution in less time than I spent
scratching my head ...

marius: As port maintainer, can you shepherd this change into the
cdrtools project?

Gregg