Hi there,

I have a problem with SuSE 9.1 when reading CD/DVD created with DirectCD under Win XP.
DirectCD is a packet writing program provided by Roxio.

When trying to mount a CD-RW/DVD +/-RW then there isn't any error message.
The media is "open" for write, so files can be added and deleted
No errors either in /var/log/messages.
However if I try to ls then I get following errors:

/bin/ls: /media/dvd/ks08: No such file or directory
/bin/ls: /media/dvd/ks09: No such file or directory
/bin/ls: /media/dvd/ks10: No such file or directory
/bin/ls: /media/dvd/ks11: No such file or directory
......

It's also not possible to cd into the directoriess located on the media.

The problem is a little bit different when I mount CD-R/DVD +/-R, which
are "closed" for write.
Then I can ls the content without any problem. I can also cd into
the directories located on the Media. The problems however occur
when I try to copy files from the media to hard-drive. As long as the
files are <= 15 MB everything is fine. If the files are > 15MB then
I can hear the CD/DVD drive slowing down and there is an I/O error
displayed.

I have tested this with a Samsung DVD ROM and a NEC 1300 Multinorm
DVD Writer. So I *guess* it's not drive related.

The CDs I used for the test can be read without any problems from SuSE 9.0
and Win XP so I also assume that the media is OK!

The funny thing is that I did not have those problems with SuSE 8.1, SuSE 8.2
and SuSE 9.0.

I have kernel: 2.6.4-54.5-default (SuSE 9.1 Pro distribution)
and UDF Driver: 0.9.8.1
Previous SuSe Versions had the 2.4.x kernel and olderUDF drivers.

Can anyone help ?
Has anyone experienced similar problems, also with other Linux distributions
or kernel versions?

Thanks in advance!

have u tried this as root: ??

mount -t udf /dev/dvd /media/dvd

Also, u cant write to cds/dvd like in direct-cd; u need to patch the kernel and install some packages for that.

UDF (the packet writing file system) has to be enabled in the kernel in order for it to be recognized and read. Actually, you even have to do this under Windows versions prior to XP (download a UDF reader and install it to the system) for UDF to be recognized (many CD burning programs provided this functionality long before XP came along).

On my 2.6.5 kernel, this option can be found in File Systems=>CD-ROM/DVD Filesystems=>UDF filesystem support. This support is available as a module, or directly compiled. It does not seem to be enabled by default, so you will have to enable it and either rebuild and reinstall your modules (if compiling as a module) or recompile your kernel (if compiling directly). I would suggest directly compiling it (my thinking being that UDF is the root filesystem of the CD and support for root filesystems should be compiled directly into the kernel), which is what I did, in case I should happen to need one of my old UDF CDs after some unthinkable emergency .

However, I don't even know where my old UDF CDs might be now (I stopped using packet writing years ago because it was just too much of a PITA to read the d*mn CDs; I'm pretty unhappy to see it making a comeback), so I can't test how it works, sorry. Packet writing has probably gone through some changes in the intervening years in any case, and the protocols have likely changed somewhat.

Hope this helps anyway.

Hello motub,
Hello vinay_s_s,

thank you for your respnses.

I have the UDF module loaded.
I mean I *can* mount a CD/DVD and lsmod shows also UDF module loaded.
No error in /var/log/messages

I also mount the CD/DVD as root exactly with mount /dev/dvd -t udf /mnt/dvd.

I use the CD/DVDs to exchange Data with some colleagues. Some of them
use Win XP and DirctCD. I know that I do *not* need DirctCD with Linux,
but some of the people I exchange data with, do use Win XP and DirectCD.

Still the question is: Why can I ls "closed" CD/DVD and change into directories,
but copying files > 15 MB fails *and* ls of mounted "open" CDs fails completely?

So even if the UDF protocol has changed in the past years this would not
explain why there is an I/O error when copying files > 15 MB.
IMHO a protocol change would mean that it would not work at all.


Plus, as already said: It used to work with prior SuSE Versions!
(Also with 9.0 which came out just end of 2003)

I would like to narrow down, where the problem comes from?
Is it distro specific ? Is it driver related or kernel related ?
Perhaps I am doing something wrong ?

"Does SuSE enable/use supermount?" is the first thing that comes to mind, for some reason. I would imagine it does; supermount was pretty broken under the 2.4 series kernels, but it seems to work well in the 2.6 series, so it's quite possible that SuSE enabled it, given SuSE's target market.

It seems to me that supermount and UDF would not mix well. Furthermore, my supermount line in /etc/fstab reads:
, which I would think is a standard line for enabling supermount, and directly contradicts the fs actually being used on the CD/DVDs.

So I might first check into disabling supermount if in use, before unmounting and remounting the drive manually to see if there was any change.

Now, this next is not going to be the clearest line of thought ever heard by man, but hang in there and see if any of it makes any sense or is useful in any way.

The other thing I'm thinking has to do with the reasons I don't like packet writing in the first place. It's confusing (in OS terms). Under Linux, to read a file from a CD, the CD must be mounted. To burn a file to a CD, the CD must not be mounted, as CD burning uses raw device access. Packet writing is halfway between the two, so how is the OS supposed to access the device? Raw or mounted? Both at once (!!!)? What backend is handling these operations? If you run K3b or gToaster, they're just front-ends for cdrecord and cdrdao and so forth, and if you copy a file from a "normal" iso9660 CD to your HDD, I guess you're just using some variant of cp. But it always seemed to me that as soon as you became involved with packet writing, you opened up a whole separate subsytem for moving files around that was not all that well integrated with standard systems (and this was under Windows, which, in this respect, you'd think would have had a better handle on the issue than you might expect from Linux).

Packet writing is some freaky merged custom I/O, so I would not feel confident that the backend for copying files from the CD is simple "cp"-- or if it is, that old reliable cp is prepared to deal with the UDF filesystem all that well (as it really didn't used to be terribly common, and is not necessarily all that stable).

OK, I had a whole additional line of thought here, but it required me to check whether the UDF kernel module is read-only or bi-directional, and doing so led me to /usr/src/<kernel_version>/Documentation/filesystems/udf.txt (which is linked in the kernel help for the UDF fs option-- who knew?):
So:

#1, you might want to check out the devel list to see if this is a known problem with a known solution;

#2, you might want to check out that website and see if there are any extra tools or applets that you might need; and

#3, you might want to mount the CDs using some of the options listed above to see if that overcomes the issues.

Do the same issues occur if you try to access the UDF fs via a GUI file manager? Sounds odd, I know, but UDF/packet writing really is a GUI-based operation (drag-and-drop, after all); maybe the old command-line tools can't handle the modern age .

Hope this helps.

Hello Motub,

thanks for your response.

Yep, suse 9.1 has subfs as default "mounter" for removable devices.

So I also thought of it as a potential problem. I have tested with and without subfs.

The results are the same.

You know subfs automounts removable media, and cd/dvd/fd appear as mounted
independent of whether there is a media in the drive or not.

So I performed also tests with disabling subfs. After reboot, umount all removable media.
modprobe -r subfs to remove the module.
Then lsmod to verify if the subfs module has been removed.
Then mounting in "good old" way, so manually.
The results are absolutely the same.

Also same results, when using GUI front-end or console mode.
Also with specifying different values for iocharset.

Just to make clear: I _just_ want to *read* UDF. _NOT_ to *write*!!

I also do not have problems with standard ISO9660 CD Roms independent of whether
created with Windows or Linux. It's the UDF stuff.

I have posted already a BUG on the UDF URL on sourceforge.net (actually two: one for the ls problems, and the other for problems with cp files > 15 MB)

There is a similar one posted some months ago, but obviously nothing happens there.

So after doing all this stuff I just wanted to narrow down the possible root cause: Distro, kernel, driver ?

P.S You may consider to change the fs= option line in your /etc/fstab to fs=cdfs which
covers both: UDF and ISO9660. Supermount can handle both!

Well, if you only have problems with one particular type of fs, then I've got to go with "driver", since it is a kernel driver. The kernel may affect it insofar as a newer kernel presumably has newer drivers, so you might consider knocking your kernel (or the driver module) back a couple of revisions to see if that helps in any way. It's also naturally possible that SuSE has tweaked the kernel in some way that affected this, but I really don't see why they would bother. Maybe I'm old-fashioned though; interoperability with XP's packet writing facilities, or with outside Windows programs that perform this function is not on my short list of priorities, but could well be on Novell/SuSE's.

Interestingly, there are two SuSE mailing lists on the subject of packet writing; any information there? At least you might expect them to know what issues were involved on both the SuSE end and the UDF end.

And yes, I do understand that you don't want to do packet writing. My point was only that packet writing, by its very nature, is a bi-directional function, and chopping the driver for the fs down to unidirectional (for whatever reason that was done) may not have gone as smoothly as people might have hoped. And, of course, there's this issue, direct from the Roxio site:
.
A file system based on UDF...? "Using packet writing technology" possibly tweaked by Roxio away from standards?

The problem may not be the kernel, the distro or the drivers. You may simply have come into conflict with proprietary/non-compliant technology.

But OK, I see you posted on this list where no one answered, but that may have been because there was already a whole discussion that had been held on the mailing list in this thread: Unable to read UDF fs on a DVD.

That poster said that s/he could mount and read the DVD in question if using ISO9660 over UDF; does that work for you?

Also, I was wondering, what type of files are these? Can you, for example, open them in the appropriate application and then save them as a file on your HDD?

Hello Motub,

thank you for your response.

In the SuSE Packet-Writing list there is nothing about my problem.
However, I posted a feedback to SuSE describing my problem some time ago.
This is the direct link to their development.
No response so far.

I know, the discussion from the kernel mailing list very well.

UDF over ISO mount ? How should that work?

What the poster *very likely* means is following. When DirectCD creates a disk it creates
a small ISO 9660 track where the UDF drivers for Windows are located. You can install
those drivers to Win systems that do *not* have UDF support. Accessing this ISO 9660 track works fine.
So if you mount the CD as ISO9660 you are accessing this partition but not the UDF partition where
data is stored.

>> [...]
>> A file system based on UDF...? "Using packet writing technology" possibly tweaked by Roxio away from standards?
>> The problem may not be the kernel, the distro or the drivers.
>> You may simply have come into conflict with proprietary/non-compliant technology.
>> [...]

So until SuSE 9.0 the format DirectCD uses for CDs, was OK but from SuSE 9.1 (UDF 0.9.8.1) on, we declare
it as non-compliant ?
I do not know if I can agree with that ? DirectCD has *not* changed it's format for years, and
obviously SuSE 9.0 had not problem with that "tweaked" format.

Besides that, what about the second problem ?
With *closed* CD (so closed for re-writing) with UDF format, at the first glance everything seems OK until
you try to copy or manipulate files with size > 15 MB.

Although I have to admit I did not read the UDF standard, I doubt that this UDF standard
says: You are not allowed to have files with size > 15 MB.

About the accessing files:

When I have a rewritable (CD+RW, DVD +/-RW) media I can not access any file.
If I have a "closed" media I can access and copy files without any problems
_as_long_as_they are < 15 MB in size.

The files are either HTML format or plain ASCII text, but I do not know why
this could have any influence on the problem.

PLUS: It really does not matter if the file names are 8.3 or long file names. Same behavior.

The problem with reading CDs/DVDs created with DirectCD (Roxio) and InCD (Nero) seems to be fixed.
After compiling kernel 2.6.7-rc2 everything works fine. Even coying larger files from UDF 1.5 CD/DVD, that
with previous kernel versions lead to an I/O Error works without any problems.

You're kidding....!

It was really the kernel driver then? Something got broke between whatever kernel SuSE 9.0 uses and this?

Well, that kinda sucks, but I'm glad you got it fixed. I've heard good things about 2.6.7-rc2 (and 2.6.7-bk9, whatever that is), so it's nice to know that I'm waiting for an actually improved kernel to make it into Portage (the Gentoo repository).

Thanks for posting back with the result, and congratulations!

I had the same problem with 2.6.6 on Slackware (can't read UDF CD's created by DirectCD on Windows).

I found this thread, downloaded and installed the 2.6.7rc2 patch and now it works.

Thanks.