[Peter Hrobar]

Hi !

I'm using InstantWrite to store some files on DVD-RAM
under W2K. I have formatted the disks with udf-2.0

When i tried to read the contents of such a DVD-RAM
from Linux (2.4.15) with the udf kernel module (0.9.5)
i got the following wierd result :
I. ls -l gives a correct list of the contents of the
DVD-RAM
II. however when i tried to extract the contents of
some of the .zip files stored on the DVD-RAM, gzip
stopped with error
III. i put back the DVD-RAM to the windows machine and
surprisingly it was not able to read its' contents
anymore

I'm just wondering whether it's because UDF2.0 is not
supported on linux (with UDF1.02 this problem
disappeared) ?

I have attached the output of chkudf.

Output of the chkudf command

• assigned_to: nobody --> bfennema

Logged In: YES
user_id=518

chkudf can't handle extended file entries, so its not very
useful. So, after you mount it under linux (rw I assume?)
you can't see anything on the disc under windows? Or the
file is just corrupt?

Anyways, if you have some free time can you download the udf
conformance tester from
http://www.extra.research.philips.com/udf/ and run it before
and after mounting under linux, and post the output.

Thanks,
Ben

Result of udf_check

Logged In: YES
user_id=315725

Thanks for your prompt reply !

Just to answer you questions :
- yes i have read/write support under linux
- after mounting the disk in linux, the files became
corrupted, (neither windows nor linux was able to read them)

What i discovered since my last posting is the following :
if i wrote one (and only one) file to the disk under w2k
then i was able to read it from linux and w2k as well
without any error

If i copied a second file to disk and then mounted it under
linux, it was not able to read the second(!) file. However
it was still able to read the first one(!). When i placed
the disk back to w2k, it was not able to read to second but
the first file.

So i'm gonna attach two separate file sets: the first
contains the output of the udf_check command before
mounting and after mounting with one file only. The second
file set contains the same, but with two files on the dvd-
ram disk.

What i'm trying to do next is to udf format the disk from
linux and let see what will happen, but unfortunatelly when
i issue the mkudf --media-type=dvdram --
blocksize=1024 /dev/scd0 on the already formatted DVDRAM
disk nothing happens ... Do you happen to know how to do
this ...

Regards

Logged In: YES
user_id=518

Could you run udf_test on the disc unmounted after writing
the second file to it, mounting it under linux, unmounting
it under linux, then trying to read it under windows and
failing..

(btw, you can read that file under windows right after
writing after ejecting the disc and sticking it back in -
or rebooting from windows to windows, right? There are some
serious spec violations in that second file =)).

I don't supposed there is a driver update for InstantWrite.
=)

Blocksize's on DVD-RAM's are still 2k, so you don't need to
specify an alternate blocksize. Also, mkudf might have
issues with the size of the DVD-RAM, but you can give it a
shot. mkudf /dev/scd0 should be all you need to run.

Does it hang, or what when you run it?

Ben

Logged In: YES
user_id=315725

Sorry, for not getting back to you sooner ... i had a lot
of thing to do.

I have formatted my dvd-ram disc under linux, but
unfortunatelly the w2k machine could not write to it (read
only).
Linux just worked fine with this disc (read-write) ...

I have decided not to play this game anymore, simply i will
not use windows(instantwrite) formatted dvd-ram under linux.

I guess instantwrite does something wrong ...

Well, thanks anyway.

• status: open --> closed

Logged In: YES
user_id=518

Well, I did find a few places where udf was screwwing up
the udf rev on 2.0+ filesystems, though I don't think that
would explain all the problems your having. The compliance
of mkudf, especially for non 1.5 discs is pretty sucky.
I've been working on a new version for a while now and it
should be much better. I may try to generate a disc with a
big file with tons of dinky extents like InstantWrite seems
to do and see if I can find any big problems with my
handling of it. I'll update this report if I find anything.