To test the problem I used my Official Debian 1.3.1 CD #1 of 2, and I
also used an old DOS video game CD (Wing Commander II and Ultima Underworld -- not that it matters). I booted into MS-DOS 6.22 and used an old utility I had called "SWEEP" that recursivly descends directories executing the specified command. I did a "SWEEP DIR /ON > D:/FILE" to get a recursive list of all files on the CD. I then rebooted into Linux, and did a "mount /dev/hdd /cdrom0 -t iso9660 -o defaults,noauto,ro,norock" to mount the CD, and then I did an "ls -R1 /cdrom0 > /tmp/scum". I copied the file listings I had created under DOS to /tmp, rand Dos2Unix on them. I then converted them to all lower-case, and did a bit of minor magic to remove non-problems from the diff.
For the Debian CD, I saw the following:
--- /tmp/scum Tue Oct 28 23:45:56 1997
+++ /tmp/scum2 Wed Oct 29 00:03:04 1997
@@ -1,3 +1,4 @@
+
bo
boot
colophon.txt
@@ -1413,7 +1414,7 @@
drv1440.bin
dselect_.htm
dselect_.txt
-install.html
+install.htm
install.txt
linux
lmemroot.bin
@@ -2521,7 +2522,7 @@
/cdrom0/boot
boot.bat
-boot.catalog
+boot.cat
linux
lmemroot.bin
loadlin.exe
@@ -2539,7 +2540,7 @@
msdos-i3
packages
readme
-readme.sourc
+readme.sou
trans.tbl
/cdrom0/contrib/binary
This, however, does not seem to be a problem with the iso9660
filesystem when mounted with "norock", since in each case, the file
"trans.tbl" says the following:
F INSTALL.HTML;1 install.html
F BOOT.CATALOG;1 boot.catalog
L README.SOURC;1 README.source-unpack ../doc/source-unpack.txt
So for this case, the only problem is that whatever was used to make the CD screwed up a few file names during the long name->8.3 translation.
Next, I checked the video game CD. No problems, both DOS and Linux listed the exact same files. I am glad to report, therefore, that I was completely unable to reproduce the problem you describe. Perhaps you could be so kind as to substantiate your bug reports in the future with conclusive evidence demonstrating the problem. I could have used my time doing something more productive after all...
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
On Tue, Oct 28, 1997 at 06:14:28PM -0500, Steven N. Hirsch wrote:
>
>
> On Tue, 28 Oct 1997, Erik Andersen wrote:
>
> > Hmm. I will look into this this evening. I have been doing a lot of work
> > on the 2.1.x CD-ROM stuff in my private development tree, but I havn't
> > noticed this particular problem. That doesn't mean that the problem
> > doesn't exist though... I will look into this this evening with 2.1.60
> > and see what I can see.
> >
> > -Erik
> >
> > --
> > Erik B. Andersen Web: http://www.inconnect.com/~andersen/
> > email: andersee@debian.org
> > --This message was written using 73% post-consumer electrons--
>
>
> Let me know if you are unable to reproduce it. It occurs reliably on two
> different SCSI drives and has been chronic since at _least_ 2.1.55 or so.
>
> Steve
>
>
>
> >
> >
> > On Tue, 28 Oct 1997, Steven N. Hirsch wrote:
> >
> > > All,
> > >
> > > Even after fixing isofs in 2.1.60, ISO filesystem handling is still
> > > broken. I've been reporting this until blue in the face, but have
> > > received absolutely zero response.
> > >
> > > For about the third time: Can ANYONE confirm or deny that there are
> > > problems with isofs/cdrom in recent 2.1.x kernels?
> > >
> > > The symptoms are simple: About 2/3 of the directory entries are simply
> > > missing. What is there seems to be correct.
> > >
> > > Thanks for any feedback whatsoever.
> > >
> > > Steve
> > >
> > >
> > >
> >
> >
> >