The original bug report incorrectly asserted that the iso9660 filesystem
was empty, sorry about that.
But this does seem to be an example (which
has been widely reported elsewhere) of a DVD with a differing udf and iso9660
filesystems. Lots of people have reported that, since Windows no longer
uses the "iso9660 udf bridge", lots of mastered DVDs have unintentionally
corrupt versions of it. Others have hinted this is done deliberately for
copy protection reasons.
-Bryce
Solving the problem by documentation
------------------------------------
The patches already supplied to mount(8) and fstab (5) give give a sysadmin
the tools to learn about and solve the problem, thanks for applying them!
It just seems like there's a bit more to say about potentially differing udf
and iso9660 filesytems on the same disc... that's the thiking behind the extra
paragraph in the patch.
Solving the problem automatically (keeping the issue out of the users face)
---------------------------------------------------------------------------
Mastering houses will test their discs on Windows. While in general emulating Windows
is something I hate, here it makes sense. The more
closely the mount automounter emulates how windows automounts, the more likely
this type of discussion will never need to come up.
According to Alan Windows tries udf first, blindly, then falls back to iso9660.
As many people pointed out, this is not a kernel issue, it's a automount
isuse.
Andries.Brouwer@cwi.nl wrote:
>
> > Here are the first 2048 1024 byte blocks.
>
> Hmm. I am a bit slow, but just looked at this image.
> It looks fine in iso9660 style, provided you give the
> nojoliet option. I get:
>
> # mount DeLorme_TopoUSA_DVD.head /mnt -t iso9660 -o loop,nojoliet
> # ls -l /mnt
> total 12
> dr-xr-xr-x 1 root root 2048 Feb 28 2001 .
> drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
> -r-xr-xr-x 1 root root 2763 Feb 28 2001 cd.txt
> dr-xr-xr-x 1 root root 2048 Feb 28 2001 data
> -r-xr-xr-x 1 root root 196 Feb 28 2001 pdataset.txt
>
> and
>
> # mount DeLorme_TopoUSA_DVD.head /mnt -t udf -o loop
> # ls -l /mnt
> total 14
> dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 .
> drwxr-xr-x 31 root root 4096 Jan 3 02:11 ..
> -r--r--r-- 1 4294967295 4294967295 2763 Feb 28 2001 CD.TXT
> dr-xr-xr-x 2 4294967295 4294967295 380 Feb 28 2001 DATA
> -r--r--r-- 1 4294967295 4294967295 196 Feb 28 2001 PDATASET.TXT
>
> so the iso9660 version looks a bit better than the udf version.
> (But I cannot look at the actual contents because the initial
> fragment is not large enough. You can check for yourself
> whether the nojoliet mount is OK.)
>
> Thus, there do not seem reasons to change mount(2) or mount(8)
> in the way you suggested. There is no "empty iso9660 filesystem" here.
>
> Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/