Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?

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]