Why would a valid DVD show zero files on Linux?

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

Confirmed. The DVD in question (DeLorme Topo USA) shows files when mounted with "nojoliet". But when the application is run, the maps are scrambled. It must be mounted as udf to work.

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.

Here is the table of contents mounted three ways. First udf, then iso9660, then iso9660 nojoliet. Only the udf version works with the application. Note that the huge udf filesizes are not a mistake - this DVD is also offered as 7 CD set.

/mnt/cdrom1/:
total 14
dr-xr-xr-x 3 4294967295 4294967295 184 Feb 28 2001 .
drwxr-xr-x 24 root root 4096 Jan 5 10:27 ..

-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

/mnt/cdrom1/DATA:
total 3266832

dr-xr-xr-x    2 4294967295 4294967295      380 Feb 28  2001 .
dr-xr-xr-x    3 4294967295 4294967295      184 Feb 28  2001 ..
-r--r--r--    1 4294967295 4294967295 34735660 Feb 28  2001 GRIDAK.DAT
-r--r--r--    1 4294967295 4294967295  1921298 Feb 28  2001 GRIDAK.IND
-r--r--r--    1 4294967295 4294967295 1832319997 Feb 28  2001 GRID.DAT
-r--r--r--    1 4294967295 4294967295 51128921 Feb 28  2001 GRID.IND
-r--r--r--    1 4294967295 4294967295    34839 Feb 28  2001 VEC.COV
-r--r--r--    1 4294967295 4294967295 1424439251 Feb 28  2001 VEC.V
-r--r--r--    1 4294967295 4294967295   643405 Feb 28  2001 VEC.VI

/mnt/cdrom1/:
total 1
dr-xr-xr-x 1 root root 1 Feb 28 2001 .

/mnt/cdrom1/:
total 12

dr-xr-xr-x    1 root     root         2048 Feb 28  2001 .
drwxr-xr-x   24 root     root         4096 Jan  5 10:27 ..
-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

/mnt/cdrom1/data:
total 22849

dr-xr-xr-x    1 root     root         2048 Feb 28  2001 .
dr-xr-xr-x    1 root     root         2048 Feb 28  2001 ..
-r-xr-xr-x    1 root     root      1181228 Feb 28  2001 gridak.dat
-r-xr-xr-x    1 root     root      1921298 Feb 28  2001 gridak.ind
-r-xr-xr-x    1 root     root      3603453 Feb 28  2001 grid.dat
-r-xr-xr-x    1 root     root       797273 Feb 28  2001 grid.ind
-r-xr-xr-x    1 root     root        34839 Feb 28  2001 vec.cov
-r-xr-xr-x    1 root     root     15153107 Feb 28  2001 vec.v
-r-xr-xr-x    1 root     root       643405 Feb 28  2001 vec.vi

As this is one clear example of differing iso9660 and udf views of the same disc, I propose to change mount(8) and fstab(5) to warn the two can be different (either intentionally, accidentally, or because of iso9660 limitations).

I also propose to change "mount -t auto" to try udf first, and fall back to iso9660. This, of course, requires more discussion first. But based on serching other lists, reading the udf "iso9660 bridge" spec, and email conversations, it seems to be the right long term answer. Since udf is used on CD's, I propose that udf be tried first for all meda, not just DVD's.

The kernel, of course, remains unchanged, and because you're using Linux, you would still be able force mount anything you want.

-Bryce