Date: Wed, 5 Jun 1996 18:19:50 -0400 (EDT) From: "Brendan Perry, HEASARC. Tel: (301) 286-1508" <PERRY@LHEAVX.GSFC.NASA.GOV> To: questions@freebsd.org Message-ID: <960605181950.2044a183@LHEAVX.GSFC.NASA.GOV>
next in thread | raw e-mail | index | archive | help
Yesterday our system manager posted the dilemma of our group's cd-rom writing. I have more details today to help understand the situation better. Basically, I created cd's on my Mac that some operating systems can't read properly. No errors occurred during the write, but the large number of files on each cd may be a factor in the file system handling of these cd's. Any help would be appreciated. The details: This cd was written on a MAC Quadra 700, driving a Pinnacle Microsystems RCD-5040. The software was Pinnacle's own CD Burner 2.1. Our old cd-writer, a Phillips CDD 521 driven by Microtest's QuickTOPix software is dead at the moment. It has hardware problems we're trying to diagnose (the main thought being it's 6 years old). We specifically adhere to ISO 9660 standards to allow the greatest number of users to access our cd's. We hold all filenames to 8.3. There is no option in the software to turn on/off RR. We created other cd's with this software, and they have none of these problems. The only significant difference between the these and the other data sets is the fact that there are 1300+ files on the other cd and 23000+ and 32000+ files on these 2 cd's respectively. Neither has more than 3 levels of subdirectories. We read and checked the cd's on several platforms here in our group. These are the results: DOS: The 'hidden' files do not show up in a general directory listing, but can be accessed if you specifically go to them. They can also be accessed with a specific "open file" from the html accompanying the cd. NeXT: The NeXT native cd-rom reading software can see all the files normally. If you use the NeXT unix-type os it acts like the PC above. ALPHA/OSF/1 V3.2: The 'hidden' files don't show up in a general directory listing, cannot be accessed with the html, and a specific 'cd' to the directory is not allowed. The files _are not there_. Sun Sparc IPX/Solaris: There are no hidden files and the files can be accessed either directly or with the html. MAC/MACOS V7.5.3: The folders containing the hidden files are not accessable either directly or with the html. I also tried FTP'ing onto the mac from elsewhere and didn't see the files. SGI: Seems to have random difficulties reading the cd's. Netscape allows access to the files, but with an odd quirk: the html lists the file links as capital letter files, but the SG filesystem lists the files as lower case, thus you get "file not found" errors, but if you do something like "open file" and use lower case you get the files to show up ok. The other thing is that if you aren't in the /cdrom directory and you do "ls /cdrom/CMA1/*" is says "not enough swap space" and hangs the machine for several minutes. --- If one does a unix 'cmp' with an original harddisk copy of the cd versus the cd itself, one gets an error message like: cmp: cannot open /cdrom/TGS/2421/RB2421_L.Z for each of the 'hidden' files. --- I read the manual that came with CD Burner 2.1 and it has several key notes I think may affect our cd burning, but the problem is that burning the cd's as I did produced NO ERRORS. Here is a sample from the Docs: If you want to create discs at double speed, you should follow these guidelines: 1) Use a computer with a 68040 or a PowerPC processor. [I have a 68040 in my Quadra 700] 2) Use a fast hard drive. [not sure what this means, but I have a dedicated 3GB ADS external harddisk partitioned into two 1.5GB partitions] 3) Defragment your source drive. [I did this with Silverlining 5.6.3] 4) Avoid file-by-file transfers containing a lot of very small files. [I couldn't 'avoid' this because I tried multiple times to use their 'create file image' but it didn't seem to want to work. However, like I said, I ran their 'predict' option and got no errors, then ran their file-by-file options and also got no errors. I also used this option with our 1300+ file cd I burned earlier] 5) Choose to predict the operation the first few times that you attempt it, to make sure that your system is fast enough. [did this, got no errors] If you run into a problem with a buffer underrun, try the following: 1) Set the software for single speed recording mode. [since I never got any write errors, I never tried this. I may do this as a test] 2) Use FILE IMAGE or DISK IMAGE recording mode to transfer your data. [provided it works, it seemed to hang my machine or else I just wasn't doing it properly. Mea culpa, but the docs don't specifically tell you how to do this, and frankly, I get a little complacent when something works with no errors yet seemingly doesn't write the files properly] I finally got through to their 'help line' and discovered it wasn't very helpful. The TS person thought that it was something physically wrong with the blank disks, or that there is an imcompatability with 4x compatable blanks and only 2x compatable writers. Well, I've been using these 4x compatable blanks with a *1x* writer for 2 years now and never experienced these errors before. The bottom line seems to be this: The writer DID write all the files to the CD, but some systems either completely can't see them, or just don't display them, but allow you to access them if you specifically go into the 'hidden directory'. The writer experienced no errors during the burn, though I did do a few 'no-nos' according to their docs (like not creating a 'file image, and not running at single speed to write, which I thought was the PURPOSE of getting a double speed writer...). The files it drops off are always the last few in a subdirectory, and the number is proportional to the number of subdirectories within the directories, but it doesn't span the 2 disks. The 23000 file cd 'lost' one sub-dir in a 183 sub-dir directory, and 'lost' 6 dirs from a 375 sub-dir directory, but the 32000+ cd 'lost' only 5 sub-dirs from a 382 sub-dir directory, and also lost 5 from a 393 sub-dir directory. So, it's _approximate_ that you lose an linear number of sub-dirs depending on their total number within the topmost dir. The numbers of files 'lost' doesn't seem to me relavant because there are always many more files in the 32000 file cd within each subdirectory. Thanks for any input Brendan Perry Code 664 NASA/GSFC Greenbelt, Maryland, USA phone (301) 286-1508 fax (301) 286-1629 email perry@lheavx.gsfc.nasa.gov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?960605181950.2044a183>