Thomas Schmitt wrote: > Hi, > >> /dev/sr1: flushing cache >> /dev/sr1: closing track >> /dev/sr1: closing session >> :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output >> > > Such a message is rarely harmless. > The drive wrote everything but failed > to finish properly. > Well, that's what I thought, but Andy Polyakov commented here:
http://www.mail-archive.com/[email protected]/msg12106.html that it was "harmless" though I'm not sure if his comment applies in this instance. >> Mount works ok: >> However, there doesn't seem to be anything there: >> smally$ ls -a /mnt >> . >> > > So the file tree was not read properly. > No chance to verify any data this way. > > I see two possible reasons of failure here: > - MMC which rules the writing of data to the > media. > - UDF which rules the reading of file tree > and the access to file contents. > > To check the correctness of the MMC writing > process, compare the whole media content with > your image file > dd if=/dev/sr1 bs=2048 count=20971520 | \ > diff - /video/oldc_backup.udf > > If this verifies correctly, then UDF mount > is to blame. Possibly it does not find its > superblock. > For help with UDF checking you will probably > have to look at some other mailing list. > I should have run the command above already. I've done it now and I see: smally$ sudo cmp /dev/sr1 /video/oldc_backup.udf ; echo $? /dev/sr1 /video/oldc_backup.udf differ: byte 8585217, line 20010 (my command seemed simpler :-) and as effective) So again I fired up python so I could easily seek around in the disk and udf image and read the block at 8585216 (cmp's reported offsets are origin-1, how annoying eh?). When I read the block from /dev/sr0 what I get back is all-zeroes. The corresponding block on the udf image is full of non-zero data. The preceding 2048 byte block on both media are full of non-zero data. Now that I'm on it, I noticed that 8585216 % 64Ki == 0, so this block is indeed at the start of a Blu-ray block (wikipedia says that BD blocks are 64KiB). Exploring further, I noticed that the next 2048-byte block following 8585216 on /dev/sr1 is non-zero. In fact, looking at it I can see that it is the program header of a windows exe. So it is in fact the logical start of a file. Strange no? Could it be coincidence? Noting that in the mediainfo we see: BD SPARE AREA INFORMATION: Spare Area: 65088/65536=99.3% free Could it be that there was a defect and things were relocated? I don't really know how the spare area is used. BTW Thomas thanks for the info about xorisso! -- Jens B. Jorgensen [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
