Scott Long <[EMAIL PROTECTED]> 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 -- Dag-Erling Smørgrav - [EMAIL PROTECTED]
--- mkisofs/write.c.orig Thu Jun 23 17:16:26 2005 +++ mkisofs/write.c Thu Jun 23 17:19:13 2005 @@ -1238,7 +1238,8 @@ } dwpnt->next = NULL; dwpnt->size = s_entry->size; - dwpnt->extent = last_extent; + dwpnt->extent = dwpnt->size ? + last_extent : ISO_BLOCKS(1); set_733((char *) s_entry->isorec.extent, last_extent); s_entry->starting_block = last_extent;
_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
