Bug 700884 - CD reads in wiindows but not in fedora
Summary: CD reads in wiindows but not in fedora
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 14
Hardware: i686
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-29 18:06 UTC by rmknox
Modified: 2012-08-16 13:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 13:55:13 UTC
Type: ---


Attachments (Terms of Use)
dump of cds (3.64 KB, text/plain)
2011-04-29 18:07 UTC, rmknox
no flags Details
formatted dump of cd that works on windows and apple but not fedora (17.24 KB, text/plain)
2011-05-04 00:37 UTC, rmknox
no flags Details
inproved formatted dump (18.02 KB, text/plain)
2011-05-04 16:20 UTC, rmknox
no flags Details

Description rmknox 2011-04-29 18:06:38 UTC
Description of problem:
I have an Intel P4 on a MSI motherboard. Fedora 14 on drive 0, win98 on drive, F11 lets me pick

Just bought a book with CD. CD has various forms.

When I boot on win98 it sees the contents of the CD. When I boot on Fedora it does not.  The CD mounts and shows
[code]
/dev/sr0 on /media/BOOK2XTRAS type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500)

[/code]

Nautilus shows the Volume Identifier from the Primary Volume Descriptor, but it shows it as empty. File system type: isofs, 0 bytes used, 0 bytes free, Total capacity: 0 bytes.

Per the dump the Cd was made by Cdeverywhere 2.0 build 67.

I can use dd to create a file consisting of the complete disk if you wish, or selected parts as you choose. I've attached a dump of the beginning of the active area, and one with a similar dump from a win98 distribution  that works on both windows and fedora.

Version-Release number of selected component (if applicable):
2.6.35.12-90.fc14.i686

How reproducible:
100%

Steps to Reproduce:
1. put this CD into drive
2.
3.
  
Actual results:
Mounts with correct name and says the CD is empty

Expected results:
Should display directory

Additional info:

Comment 1 rmknox 2011-04-29 18:07:50 UTC
Created attachment 495828 [details]
dump of cds

Comment 2 rmknox 2011-04-29 18:09:33 UTC
type above - win98 is on drive 1

Comment 3 Ondrej Vasik 2011-04-29 18:47:44 UTC
Filesystem package has nothing to do with your problem - it just contains base directory hierarchy. 

I'm not sure which component is responsible for your issue, I guess probably incorrect mount options are used ... don't know, though.
I'll try to reassign to util-linux (mount utility) as first step, Karel, feel free to reassign to "better component" if you know one.

Comment 4 rmknox 2011-04-30 02:03:08 UTC
I notice one difference between this CD and all my others. It regards the reaction of the system when I insert the CD into the drive.

If I have nautilus displaying my /media folder and I insert my win98E CD (for example) into the CD drive, the nautilus display stays on the /media folder and the icon for the new Cd appears on that page.

If I have nautilus displaying my /media folder and I insert the offending CD into the drive, nautilus opens a page for that CD - which page is blank merely showing the name of the CD at the top. 

When I display properties, both are essentially the same. They show type (inode/directory) freespace unknown, isofs. The win98SE CD shows that there are 3888 items total 632.0 MB whereas the other CD shows "nothing". HOwever, when I query the offending CD under windows I see its contents.

Comment 5 rmknox 2011-05-02 07:03:39 UTC
You may want to hold off. I am researching the problem and it appears that CDeverywhere creates really wierd CDs. The publisher says I am the first to complain - and I'm not finished, but their Cd appears to be missing the path files and also missing the ascii  directories. I only see directories in 16 bit characters. Maybe I have not properly diagnosed it, but hold off. I dont think you can do much without the CD in question. I will let you know more as I study it more.

Comment 6 rmknox 2011-05-04 00:31:29 UTC
Regarding the CD that lists on windows but not on Fedora.

Unless I'm wrong, the problem happens when we mount the disk, since more than 1 utility thinks it is empty.

I've written a program to format a dump of the CD.
The program displays the contents of the volume descriptor, then follows the path file and lists its contents, then follows the directory file and lists its contents.

This is repeated 3 times since the CD has 3 volume descriptors.

The CD has two type 1 Volume descriptors and one type 2 volume descriptor. The two type 1 volume descriptors point to an empty path file at sector 22 and an empty directory structure at sector 20.

The type 2 volume descriptor points to a different path file and a different directory. These are located at sector 41 and sector 24. These 2 describe the contents that display when you view the disk from win98se. 

I don't know enough about the ISO spec to understand the implications of having the 3rd volume descriptor on the CD point to the data.

I'm attaching my dump.

Comment 7 rmknox 2011-05-04 00:37:22 UTC
Created attachment 496668 [details]
formatted dump of cd that works on windows and apple but not fedora

this goes with comment i just posted

by the way, when i isssue the mount command when this CD is mounted it shows 
[code]
/dev/sr0 on /media/BOOK2XTRAS type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500)
[/code]
when i issue the mount command with my win98se disk mounted it says
[code]
/dev/sr0 on /media/WIN98 SE type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500)
[/code]
they mount the same

Comment 8 Karel Zak 2011-05-04 07:20:18 UTC
Please, try:

   # blkid -p -o udev /dev/sr0

and copy & past the output to bugzilla. Thanks.

Did you try to mount the CD manually by command line? (mount /dev/sr0 /mnt/foo).

Comment 9 rmknox 2011-05-04 14:36:03 UTC
[knox@knox ~]$ blkid -p -o udev /dev/sr0
ID_FS_LABEL=BOOK2XTRAS
ID_FS_LABEL_ENC=BOOK2XTRAS
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
[knox@knox ~]$ 


I believe I have figured what the problem is

The Cd uses 16 bit charactters in its directories. The dump shows that the high byte of each int is null. When I list the directorties I need to code it as

for (ii=0; ii< namelen;ii++) if (buff[ii] > ' ')printf("%c",buff[ii]);

and I get a printed string 1/2 the size of namelen.

Fedora mounts it the way it would as if it were using 8 bit characters.

There are 3 Volume Descriptors. The first two are type 1. Both of these point to an empty directory and an empty path file.

The 3rd file descriptor is type 2. It calls for escape code processing and in the escape code field it lists 0x25 0x2f 0x40.

I believe fedora is mounting the disk as if it were using 8 bit characters, referring to the empty director/path file, and concluding that it is empty.

I assume this is a flaw in the selection of the automagic mount command.

As a work around and to prove my theory, I would like to know how to mount it manually so as to recognize the info in the type 2 volume descriptor, ie so as to accommodate the escape sequence logic. The instructions for the mount command leave me confused.

Comment 10 rmknox 2011-05-04 14:49:55 UTC
Regarding mounting from the command line

the system auto mounts - but in a way that finds the empty directory

i am lost in the complication of the mount command, and have had no success in mounting manully or for that matter no success in decoding the documentation.

i should admit i'm 80 years old - maybe my decoding skills are diminishing

Comment 11 rmknox 2011-05-04 16:20:52 UTC
Created attachment 496841 [details]
inproved formatted dump

modified the dump program to reflect my improving knowledge of iso9660 type 2 volume descriptors, and added notation on directory listing to show when wide characters are found. (in this case all directory characters are wide characters)

Comment 12 rmknox 2011-05-05 21:00:18 UTC
I FOUND IT! The extra type 1 Volume Descriptor is the problem. Fedora14 works just right if the 2nd volume descriptor is the type 2 volume descriptor.

To compare with the CD which doesn't mount correctly, I have a CD which I made using NERO. I dumped some data from my win98 disk, running in win98. The Cd has 2 Volume Descriptors. A type 1 and a type 2. The type 2 calls for the escape sequences associated with wide characters and long file names.

When I put my NERO disk on Fedora14, fedora correct identifies it as wide characters and long file names. Fedora has processed the type 2 volume descriptor.

{
As an interesting side note, NERO also created a set of 8.3 file name directories for the type 1 volume descriptor, and populated these directories with 8 bit characters. It takes the first 8 characters of the file name. If I transverse  that directory structure with a little utility I wrote, I correctly find the files on the CD. Both the 8bit directory and the 16 bit directory ultimately point to the same files.
}

The CD which has been causing trouble has 3 volume descriptors: a type 1, a copy of the type 1, and a type 2. The directory structure for the type 1 8bit character directories has merely the root directory header. The directory structure that starts on the type 2 volume descriptor has the complete contents of the disk, in 16 bit characters, with long file names. This sub optimal CD was created with a program called CDeverywhere. When I sent an email to the folks at CDeverywhere they did not bother to respond.

When I put that CD on Fedora 14, Fedora shows me that it is empty. Fedora is using one of the two identical type 1 volume directories.

Fedora did not see the 3rd sector, which has the 3rd volume descriptor, which is type 2 and which specifies long file names and wide characters. 

The way my utility works is that i iterate through all the volume descriptors until i find the EOF descriptor (type 0xff). I suspect that win98 does the same. Maybe the Fedora program that analyzes the Cd merely assumes that if there is a type 2 descriptor it will be record 2.


Finally, whatever the difference between the one that works and the one that does not, mount reports them as if they were the same


mount with my nero -- this one works
/dev/sr0 on /media/My Disc    type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500)
mount with his book -- this one does not
/dev/sr0 on /media/BOOK2XTRAS type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=500,gid=500,iocharset=utf8,mode=0400,dmode=0500)

Comment 13 rmknox 2011-05-07 04:59:35 UTC
Its interesting to see that disktype sees the CD accurately
Note the last 2 lines - it sees the volume name which is encoded in 16 bit characters in the type 2 Volume Descriptor

[root@knox BOOK2XTRAS]# disktype /dev/sr0



--- /dev/sr0

Block device, size 49.76 MiB (52174848 bytes)

CD-ROM, 1 track, CDDB disk ID 02015301

Track 1: Data track, 49.76 MiB (52174848 bytes)

  Apple partition map, 2 entries

  Partition 1: 1 KiB (1024 bytes, 2 sectors from 1)

    Type "Apple_partition_map"

  Partition 2: 49.46 MiB (51860992 bytes, 101291 sectors from 3)

    Type "Apple_HFS"

    HFS file system

      Volume name "Book 2 Xtras"

      Volume size 49.43 MiB (51828736 bytes, 25307 blocks of 2 KiB)

  ISO9660 file system

    Volume name "BOOK2XTRAS"

    Publisher   "ED SHERMAN, NOLO PRESS-OCCIDENTAL"

    Preparer    "ED SHERMAN"

    Data size 49.46 MiB (51863552 bytes, 25324 blocks of 2 KiB)

    Additional Primary Volume Descriptor

    Joliet extension, volume name "Book 2 Xtras"



[root@knox BOOK2XTRAS]#

Comment 14 Fedora End Of Life 2012-08-16 13:55:16 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.