linux-kernel - iso9660 vs udf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 15 Sep 2007 23:49:31 +0200
From:	"Andries E. Brouwer" <Andries.Brouwer@....nl>
To:	linux-kernel@...r.kernel.org
Subject: iso9660 vs udf

Today I got a CD. MacOS does not mount it and Linux does not
mount it without an explicit filesystemtype option.
That is,
	# mount /dev/hdc /dir -t iso9660
works fine, but
	# mount /dev/hdc /dir
	mount: you didn't specify a filesystem type for /dev/hdc
               I will try type udf
        mount: wrong fs type, bad option, bad superblock on /dev/hdc,
               missing codepage or other error
               In some cases useful info is found in syslog - try
               dmesg | tail  or so
	# dmesg | tail
        UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Wisk1956-82', timestamp 2006/03/07 16:26 (1078)
        udf: udf_read_inode(ino 547) failed !bh
        UDF-fs: Error in udf_iget, block=1, partition=1

Google gave me half a dozen other people that mentioned the same
problem (with the same inode 547). Clearly some CD mastering software
produces a format that Linux and MacOS do not handle easily.

One result of this letter will be that people with the same problem
learn via Google that using the "-t iso9660" option may help.

What goes wrong on the mount side is that when it hesitates between
iso9660 and udf it decides for udf when seeing "NSR02".
Maybe the heuristics in mount should be tuned.

On the other hand, this filesystem announces itself as UDF
("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
perhaps the kernel code should be more robust.

If anybody feels responsible for mount and/or this kernel area
we might discuss.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/