Hi, I need to recover some data from a DVD formatted as UDF. (I first formatted the DVD using dvd+rw-tool and mkudffs and used it in conjunction with pktsetup for packet writing.) In any case, I had three rather large (~1.5 GB) files on the disk. I accidentally cut (rather than copied) them from the DVD.

I modified them but I would like to get the originals back if possible. The DVD hasn't been written to since then, so whatever file structures should be there. I made a dd image of the DVD but can't figure out what to do with it--seems to me dvdisaster can't handle UDF. Any suggestions?

Does testdisk or photorec handle udf?

Thanks for your reply. The web pages for those apps don't mention UDF--but after reading their pages it looks like this might not work in this case... The files that I need to recover are, ironically, parts of another img file (itself an image of an ext3 file system). Here's what happened

I used dd, using block size=512 bytes, to create a backup of an ext3 file system resulting in a file of 17928477 blocks.

I ran dd again to split this file into six parts. Five of these parts have length of 2987746 blocks with the sixth part having a slightly different size. I put three files on each DVD. The DVD containing the first three files is the one in trouble. The three files were just named 'part1' 'part2' and 'part3'.

The dd img file I mentioned in the first post is an image of the troubled dvd so there's basically a double dd going on here. If I use something like dd if=dvd.img seek=x count=y of=filename and then say "cat filename" I can see lots of human-readable stuff going by, some of it familiar, so I know the "stuff" is still there.

But saying dd if=dvd.img count=2987746 of=part1 can't work--there must be sparing table somewhere in dvd.img. Furthermore, just formatting the DVD to udf takes space. I'll have to think about this some more. I might try formatting another blank dvd the same way and putting, say, 5 human readable text files on it, making a dd image, and then seeing if one can find where the boundaries of the files are.

Well I figured it out and thought I'd divulge the secret in case it can help someone else. (First I should say I tried using a program called isobuster (under wine) and it tried to recover stuff inside the dd image rather than the image parts themselves, so that was a no go.)

First I formatted a "virgin" DVD+RW like so:
I then wrote some human readable files to this disk, made an image of the DVD using dd (or at least the first 100 MB of the disk). I opened the image file in a text editor and found the beginning of the first text file. (As much as I like vim, emacs sure delivered here :-)) Shortly before this appear the list of filenames that appear on the disk as well as the string "Non-Allocatable Space". Important: The first text file actually starts IN the end of this line, NOT at the beginning of the following line.

I then made some small images from segments of the image of the troubled dvd, observing the regions around where the beginnings and ends of the files were thought to be (based on number of blocks = bytes / 512) and found a "padded" region of six blocks containing the string "*Linux UDFFS". Finally, I searched the beginning of the file for "Non-Allocatable Space" and then skipped ahead to the end of this line and found what I thought was the end of the UDF structure and the beginning of the first file, as above. Thus I was able to extract the first file using the known number of blocks, though it was offset by (# of blocks in UDF structure + 6). Accounting for a six-block pad between the other files, I recovered the next two files seamlessly.

This might sound simple, but this was a lot of trial and error here. In sum, UDF DVD's

- have a "structure" at the beginning of the disk that contains the names of files on the disk even if they have been deleted or else cut/copied away. This structure is approximately 9226 blocks long, though this varies depending on how many file names are in it.

- place six blocks (3072) bytes between files, which is mostly not human readable except for the string mentioned above.

I was able to piece everything back together, although when I tried to mount it, the superblock was apparently bad. I was able to restore this though. So now I am able to mount this image file as ext3.