Bug 19782 - cd9660(5) uses non-unique inode numbers for hard links
Summary: cd9660(5) uses non-unique inode numbers for hard links
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-07-08 08:20 UTC by mackler-fb
Modified: 2021-08-21 16:42 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mackler-fb 2000-07-08 08:20:00 UTC
	When using mkisofs 1.12.1 from the ports collection, hard
	links in the source tree are not preserved in the ISO9660 that mkisofs
	creates.

Joerg Schilling <schilling@fokus.gmd.de>, who is listed on the man page as
the maintainer says by email (7 Jul 2000):

    " . . . send a bugreport to the Freebsd kernel team. Mkisofs is OK,
    the bug is in the FreeBSD filesystem code."

How-To-Repeat: 
	Do this:

	1) make a test directory:
		mkdir /tmp/exampletree

	2) make a test file:
		touch /tmp/exampletree/file1

	3) make a link to the test file:
		ln /tmp/exampletree/file1 /tmp/exampletree/file2

	4) take a look and see the hard link:
		ls -li /tmp/exampletree/

	   see (notice files have same inode):
			total 0
			14 -rw-r--r--  2 mackler  wheel  0 Jul  8 06:48 file1
			14 -rw-r--r--  2 mackler  wheel  0 Jul  8 06:48 file2

	5) use mkisofs to make an iso9660 filesystem:
		mkisofs -o /tmp/iso9660.test /tmp/exampletree/

	6) mount the new iso9660 filesystem:
		vnconfig -cv vn0 /tmp/iso9660.test
		mount_cd9660 /dev/vn0c /mnt

	7) take a look and see the two files are not linked:
		ls -li /mnt 

	   see (notice files have different inodes):
			total 0
			47172 -r-xr-xr-x  1 root  wheel  0 Jul  8 06:48 file1
			47214 -r-xr-xr-x  1 root  wheel  0 Jul  8 06:48 file2

	8) clean up:
		umount /mnt
		vnconfig -u vn0
		rm /tmp/iso9660.test
		rm -rf /tmp/exampletree/
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-07-10 13:43:24 UTC
Responsible Changed
From-To: freebsd-bugs->dirk

Dirk, could you chase up on this?  I realize that the PR 
suggests a bug in a part of FreeBSD which is not your 
area, but since you're the maintainer of the port, you 
might be a good person to run around asking the right 
people the right questions. :-)
Comment 2 Kris Kennaway freebsd_committer freebsd_triage 2004-02-22 02:00:34 UTC
Responsible Changed
From-To: dirk->freebsd-ports-bugs

dirk no longer maintains this port
Comment 3 Oliver Eikemeier freebsd_committer freebsd_triage 2004-05-10 19:10:38 UTC
Responsible Changed
From-To: freebsd-ports-bugs->marius

over to Marius Strobl, who is the port's maintainer and a src committer ;)
Comment 4 Marius Strobl freebsd_committer freebsd_triage 2004-05-11 16:10:28 UTC
State Changed
From-To: open->analyzed


This was "fixed" in sys/isofs/cd9660/cd9660_vnops.c rev. 1.77, which 
in turn broke NFS readdir plus support (PR 63446). While this NFS 
problem is considered second order I somewhat hesitate to just MFC 
cd9660_vnops.c 1.77 and I'm not yet sure what to do in order to also 
fix this in RELENG_4.
Comment 5 Marius Strobl freebsd_committer freebsd_triage 2005-08-10 22:28:37 UTC
Responsible Changed
From-To: marius->freebsd-bugs@FreeBSD.org


Assign back to the pool as I have have no idea what to do about it (the 
fix in rev. 1.77 of sys/isofs/cd9660/cd9660_vnops.c was backed out in rev. 
1.99 again) and this also isn't about cdrtools/mkisofs (which I also no 
longer maintain). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19782 

Adding to audit trail manually by bugmeister on 20080125:
 
 bugbuster vwerth@ confirms that this is still a problem with 7.0-RC1.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2012-07-01 17:10:29 UTC
State Changed
From-To: analyzed->open

unowned PRs must not be in analyzed state
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:26 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 8 Eugene Grosbein freebsd_committer freebsd_triage 2018-02-02 20:43:20 UTC
mkisofs is not and was not part of base system
Comment 9 Walter Schwarzenfeld freebsd_triage 2018-02-03 01:04:24 UTC
It belongs to cdrtools.
Comment 10 Walter Schwarzenfeld freebsd_triage 2018-02-03 01:04:41 UTC
Problem still exists.
Comment 11 Marius Strobl freebsd_committer freebsd_triage 2018-02-03 02:02:14 UTC
As already stated in my comments from 2004-05-11 16:10:28 UTC and
2005-08-10 22:28:37 UTC respectively, this in fact isn't a bug in
mkisofs. The problem is that cd9660(5) doesn't use unique inode
numbers for hard links, which had been plugged with a quick fix in
r97094, but that changed has been "temporarily" reverted in r134807
again as it in turn broke NFS readdir plus support.

Thus, change the synopsis accordingly and assign back to default.
Comment 12 Eugene Grosbein freebsd_committer freebsd_triage 2021-08-21 16:42:25 UTC
Tested with 12.2-STABLE/amd64 and problem is still here.