Re: how to rescue this backup data
Hi,
> That is kind of wired!! Because:
> 1256119 - 23 = 1256096
> as I said, I have:
> Track Start Address: 1256096*2KB
> The backup operator did not make a mistake.
So you will have to re-attach his head now
resp. pull the needles out of the voodoo doll ?
> UDF-fs: No anchor found
This is a ISO 9660 / UDF hybrid image.
It would be interesting to see what happens if
you load it into xorriso (which ignores UDF).
> 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/
> ns.asp mm_menu.js
> 1_old.html global.asp mm_menu1.js
> So now I got my backup data.
Congrats.
> What did I revealed? Was there a bug in kernel module for iso9660? Was
> there a bug in mkisofs?
The filesystem image in the first session has
two directory trees:
The one of ISO 9660 (public as ECMA-119) and the
one of UDF (ECMA-167 plus UDF-2.60).
The one of UDF seems to be a problem to the
filesystem code in the kernel.
That is not always so. Possibly it is confused
by the second session being there. The "anchor"
is possibly searched from the end of the readable
area on media.
The second session obviously has no such problem.
Probably because it contains no UDF tree.
Multi-session and UDF may be rarely tested.
Maybe you get a better result with
mount -t iso9660 ...
so that mount does not pick UDF as first choice.
Anyway, if it works that way then you will
see the files from the _first_ session only.
Multi-session on DVD in general is not well
supported by the Linux kernel. With CD you can
issue
-o session=2
but that does not work with CD.
Luckily there is
-o sbsector=
So you just need a helper program, like
dvd+rw-tools and a bit of knowledge.
<Advertising on>
Somewhat more comfortable would have been to
perform as superuser:
# xorriso -osirrox on \
-mount /dev/sr0 session 2 /mnt
which would have searched for the right sbsector
and issued this command via execv()
mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=992400 '/dev/sr2' '/mnt'
If you are cautious you can as normal user let
xorriso just format and print the command
$ xorriso -osirrox on \
-mount_cmd /dev/sr0 session 2 /mnt
...
Volume id : 'UPDATE_HOME_2009_09_06_195015'
mount -t iso9660 -o nodev,noexec,nosuid,ro,sbsector=992400 '/dev/sr2' '/mnt'
$
xorriso can search for volume ids too:
-mount_cmd /dev/sr0 volid '*2009_09_06*' /mnt
Finally, xorriso can record ACLs, equip data
with MD5 checksums, equips superblock, file tree
and overall image with MD5, does multi-session
on optical media, files and block devices (e.g.
USB sticks).
It does not allow the user to confuse disks,
because in its normal operation the whole
transaction of getting the -C values and of
applying them is done within a single program
run.
For the purpose of multi-session backup, xorriso
outperforms mkisofs by far.
This example produces a daily update session
of /home/thomas/open_source_projects and
/home/thomas/personal_mail. Before the media
gets ejected, that session gets checkread by its
now recorded MD5:
$ xorriso -for_backup -disk_dev_ino on \
-assert_volid 'PROJECTS_MAIL_*' FATAL \
-dev /dev/sr0 \
-volid PROJECTS_MAIL_"$(date '+%Y_%m_%d_%H%M%S')" \
-not_leaf '*.o' -not_leaf '*.swp' \
-update_r /home/thomas/open_source_projects /open_source_projects \
-update_r /home/thomas/personal_mail /personal_mail \
-commit -toc -check_md5 FAILURE -- -eject all
You can checkread the sessions at any time later
again. The checksumming survives even copying
from media to media. xorriso can search sessions
in single session copies of multi-session media.
The checksum tag blocks are recognizable outside
the ISO filesystem and they tell their original
address as cleartext. We would not have had to
guess positions from ECMA-119.
xorriso is under GPL:
http://scdbackup.sourceforge.net/xorriso_eng.html
<Advertising off>
Have a nice day :)
Thomas
Reply to: