Need Data recovery program

[Jerry Blumenthal]

One of my users has sent me a set of badly damaged files from a "backup". I
ran CHECKFB on the files and some were ok, but several gave me the response:
"makes no sense". I need to write a data recovery program, and wondered
if anyone else had done anything like this. My idea is this:

1. open the file as a file of pascal records, with size of record= to size
of old record
2. also open a new BTF file
3. read a block of bytes from the damaged file and examine it to see where
the data might lie, and superimpose that on the btf file's record. If last
name and first name do not fit the new btf record properly, I will know it
isnt right, and will need to change the offset.. Once I have the offset
correct, I can just read from the old and write to the new.

Does this make sense? Has anyone done anything like this?

(original files were btf 5.55, BP7. )

--
Jerry Blumenthal
je...@blumenthalsoftware.com

[Rob Roberts [TPX]]

Jerry,

It sounds like you are assuming that records have somehow gotten shifted
around within the data file, so that they aren't located on the correct
offsets. If that assumption is true, then it sounds like the method you
described might work, but that's a pretty big assumption. It's hard to
imagine how the records would have gotten shifted around like that.

Is the backup data file that your user sent you evenly divisible by the
record length? If so, the "makes no sense" message you're getting from
CHECKFB might just mean the header record is damaged. Did you reserve the
first 4 bytes of each record for the "status" or "deleted" field? If so,
you can try reading the file sequentially as a regular Pascal file of
records. Ignore the first record (record #0) and any that have non-zero
status fields, and add all the rest to a new fileblock. That's what I would
try first.

--Rob [TPX]

"Jerry Blumenthal" <je...@blumenthalsoftware.com> wrote in message
news:FajnkETm...@tpsmail01.turbopower.net...

[Jerry Blumenthal]

Thanks for the suggestion. My thought had been that the filer file header
was damaged and that that was why CheckFb gave those results.

However, I downloaded a hex editor and looked at his file. It is all #0 -
every single byte is a zero. I dont know how this guy was backing up his
files, maybe with a shredder. Anyway, no reason to look further, there's no
data there and I've told him so.

Unless he has a backup which does have files with data, I'm sure not going
to work on this idea any more.

Jerry

[Jerry Blumenthal]

Thank you! Since his data looks liked it was wiped clean by something like
WipeFile, I cant use it now, but the procedure you gave me is exactly what I
was looking for.
Jerry

"CVSoft Informática Ltda" <cvs...@cvsoft.com.br> wrote in message
news:5w01VlX...@tpsmail01.turbopower.net...
> I have create a tool to solve this. It works only if you have the rec size
> and the file is sequentialy correct:
>
> Assign(F,MyOldDataBase);
> Reset(F,1);
> BlockRead(F,Buffer^,MyDataRecSize,BytesRead); { This is the file header,
> ignore it);
> While (BytesRead>0) do
> begin
> BlockRead(F,Buffer^,MyDataRecSize,BytesRead);
> If BytesRead=MyDataRecSize then BTAddRec(......);
> end;
> Close(F);
>
>
> --
>
> Cesar Schneider
> CVSoft Informática Ltda
> cvs...@cvsoft.com.br
> www.cvsoft.com.br
>
>

[Rob Roberts [TPX]]

Jerry,

> However, I downloaded a hex editor and looked at his file. It is all #0 -
> every single byte is a zero.
>

> Unless he has a backup which does have files with data, I'm sure not going
> to work on this idea any more.

Pretty hard to recover data from that. ;) Hopefully he has some older
backups with valid data. If not, I hope it's nothing too important...

--Rob [TPX]

[CVSoft Informática Ltda]