lkml.org 
[lkml]   [1997]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: CD Filesystem still broken!
OK, I have looked into this and here is what I found...

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
> > >
> > >
> > >
> >
> >
> >

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.050 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site