[Info-vax] ODS-5 data/file recovery

[George Cornelius]

MG wrote:
> On 15-feb-2013 16:16, Simon Clubley wrote:
>> Image backup will not preserve your disk in this case; it only gives you
>> a functionally equivalent copy of the disk for files which have not been
>> deleted.
> 
> Yes, I know, but that's what I want.  (So that whatever is on there and
> could possibly be retrieved/recovered, I at least have a back-up of.)

No, that's not correct.  You want to copy the _unallocated_ blocks as
well.  Unless you are using erase on delete, you can at least hope that
the blocks of your file are present there.  It can't hurt to have a
physical backup in any event.

>> so this is from memory, but I would start by running down indexf.sys
>> and see if you can locate the file that way.
> 
> If the file was in INDEXF.SYS, then DFU would've found it.  But,
> neither I nor DFU were able to locate the file in there.
> 
> I can find the file while going through the disk in a 'foreign'
> mount.  So, where do I go from here?

I assume you mean you found the file name somewhere.  That may
not mean much - maybe some of the information is in the pagefile,
for example.  But if you actually did find the individual blocks,
it is a simple enough matter to create a new file - on a different
disk since this one's mounted FOREIGN - and copy the blocks there.

Now if you only found the file name and want to see if somehow
you are looking at a file header, you can use DUMP on a file
header block of a known file - a block of INDEXF.SYS - and compare
to the output of DUMP for the data in question.  You should be
able to recognize various points of similarity between any two
header blocks (and there are macros and SDL records defining
ODS5 header layout).

Another idea is to generate another ZIP file that is similar,
say by number of files present and data contents of the files,
and try to determine if there is something at the beginning of
a ZIP file that will ID it.  I suppose you will find, at
a minimum, the name of the first file stored within the
archive.  But that's a long road, because you will have only
come up with a way to recognize the first block of the file,
and unless the blocks were allocated contiguously, that may
not help you much with the rest of it unless you really
dig deep into ZIP file formats and find some way to recognize
the remaining data (but you could assume it was allocated
contiguously and just grab a large chunk and copy it to
another file and then try to UNZIP it).

George Cornelius

>  - MG
>