Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!osu-cis!att!cbnews!shurr
From: shurr@cbnews.ATT.COM (Larry A. Shurr)
Newsgroups: comp.sys.ibm.pc
Subject: Re: HELP! Used RECOVER instead of RESTORE
Keywords: Is there any hope?
Message-ID: <3658@cbnews.ATT.COM>
Date: 31 Jan 89 18:55:33 GMT
References: <9077@burdvax.PRC.Unisys.COM>
Reply-To: cbnews!cbema!las@att.ATT.COM (Larry A. Shurr)
Distribution: na
Organization: AT&T Bell Laboratories (actually an AGS consultant)
Lines: 46
Answer: Yes

In article <9077@burdvax.PRC.Unisys.COM> bmiller@PRC.Unisys.COM (Bruce J. Miller) writes:

>	A co-worker was attempting to retrieve some files from floppy which
>he was told had been created by using BACKUP.  Instead of using RESTORE, 
>he used RECOVER.  The result was a disk with a directory full of files
>named "FILExxxx.RES" where xxxx are sequential numbers up to the number of
>original files on the disk.  The original file names appear to be lost; it
>also appears that the number of bytes in each file has increased slightly.

RECOVER is an incredibly brain-damaged utility isn't it?  Of course,
BACKUP and RESTORE aren't much better.

Your friend can probably still restore from that disk as BACKUP stored
the original file pathname at the beginning of each backup file on the
disk and it is from there that RESTORE gets the file and pathname for each
file as it restores them.  

The files were lengthened by recover because it reset each file size to 
the exact number of bytes taken up by the each backup file on the disk 
(i.e. file size now = number of bytes per cluster * number of clusters 
in the file).  The result will probably be that each restore file will 
have some garbage at the end.

Caveat: Beware, different versions of BACKUP and RESTORE may not be
compatible.  If RESTORE says something like 'Not a backup disk' you
are using a version of RESTORE which is not compatible with the ver-
sion of BACKUP used to create the disk.

Hacker's solution:  The versions of BACKUP and RESTORE that I have had
to work with use the following format (the incompatibility seems to be in 
how the sequence file placed on each backup disk is named and what data 
are written in it):  Each backup file consists of: 1) A 128-byte header
containing the file's original pathname, followed by 2) the file data.
If the a file is split across two or more disks, each segment of the
file is stored using the above format.  Your job will be to extract
each file segment and concatenate them together to recover the original
file ("COPY/B" should do it).  Go for it.

Guarantee: None.  Good luck.

Regards, Larry
-- 
Signed: Larry A. Shurr (att!cbnews!cbema!las or osu-cis!apr!las)
Notice: 'R'eply WILL NOT reach me - try above addresses, OK?  Thanks.
Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave
(With apologies to the real thing.  Above represents my views only.)