Re: how to rescue this backup data

[Zhang Weiwu <zhangweiwu@realss.com>]

在 2010-01-03日的 20:11 +0100，Thomas Schmitt写道：
> Hi,
> 
> it comes to me that 1256091 is not a probable
> exact start address. It should at least be
> divisible by 16.
> Well, check what is written in the first
> sessions. Hopefully this will yield a better
> number than 28. 0x17 = 23 would be nice.

That is kind of wired!! Because:
1256119 - 23 = 1256096

as I said, I have:

        # dvd+rw-mediainfo /dev/sr1 | grep -A 4 "#2.:"
        READ TRACK INFORMATION[#2]:
         Track State:           partial/complete
         Track Start Address:   1256096*2KB
         Free Blocks:           0*2KB
         Track Size:            155440*2KB

So it shows the 2nd session track start address 1256096 is what you
guessed.

This means, the DVD+R that was there in /dev/sr0 /had been/ the DVD+R
that was there in /dev/sr1. It was the same disk! The backup operator
did not make a mistake.

But then why mount would not work?
        
        Jamaica:~ # mount /dev/sr1 /mnt/
        mount: block device /dev/hdc is write-protected, mounting
        read-only
        mount: wrong fs type, bad option, bad superblock on /dev/hdc,
               missing codepage or helper program, or other error
               In some cases useful info is found in syslog - try
               dmesg | tail  or so
        
        Jamaica:~ # mount -o session=1 /dev/sr1 /mnt/
        mount: block device /dev/hdc is write-protected, mounting
        read-only
        mount: wrong fs type, bad option, bad superblock on /dev/hdc,
               missing codepage or helper program, or other error
               In some cases useful info is found in syslog - try
               dmesg | tail  or so
        
        Jamaica:~ # dmesg | tail
        wlan0: authenticate with AP 00:25:86:01:8a:de
        wlan0: authentication with AP 00:25:86:01:8a:de timed out
        grow_buffers: requested out-of-range block 18446744073708710576
        for device hdc
        UDF-fs: No anchor found
        UDF-fs: No partition found (1)
        UDF-fs: No anchor found
        UDF-fs: No partition found (1)
        
This is really wired. I think I should just try my luck by using:
        
        Jamaica:~ # mount -t iso9660 -o sbsector=1256096 /dev/sr1 /mnt/
        mount: block device /dev/hdc is write-protected, mounting
        read-only
        Jamaica:~ # ls /mnt/
        1.html                functions.asp           mm_menu.js
        1_old.html            global.asp              mm_menu1.js
        ....

So now I got my backup data.

What did I revealed? Was there a bug in kernel module for iso9660? Was
there a bug in mkisofs?

Anyway, thanks for providing necessary information that I finally got
the backup data.