Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!rlgvax!vrdxhq!bisanabi
From: bisanabi@vrdxhq.UUCP (Paul Paloski)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Recovering file that DIR says is 0 bytes.
Message-ID: <4156@vrdxhq.UUCP>
Date: Sat, 25-Jul-87 15:09:40 EDT
Article-I.D.: vrdxhq.4156
Posted: Sat Jul 25 15:09:40 1987
Date-Received: Sun, 26-Jul-87 02:21:44 EDT
Organization: Verdix Corporation, Chantilly, VA
Lines: 94


Well, I got my file back.  So far no ill effects.  First, the last
summary of responses, then what I did to retrieve the file.

>From: seismo!ames.arpa!ucbcad!violet.berkeley.edu!ephram
>
>A person at work asked me a question just like yours and I directed her to
>norton.  It also didn't work for her.  She then tried chkdsk and found
>32 lost clusters in 1 chain! :-) pay dirt.  Her file was there in its
>entirety. If that didn't work I would try following the chain as pointed
>to by the 0 size directory entry  theory being that all the clusters
>are there but the file size was never updated via the close function.
>

CHKDSK did *not* work for me.  It ran through its thing, and listed
the disk status.  No extra chains.  The 'starting cluster' in the
directory table was also set to *zero* !  I could therefore not just
bump the file size counter up, nor use the listing for finding the
start of the cluster chain.

>From: seismo!ames.arpa!sdcsvax!hp-sdd!ncr-sd!ocean!rock
>
>Try running chkdsk which will collect all of the segments into a file
>called FILE0000.CHK in your root.  You can then rename, edit,
>whatever...

Similar to the above.  The command would not work.

>From: seismo!ihnp4!drutx!rrg
>
>The problem is not with the FAT, its that the directory entry has not
>been updated (typical of old-style FCB file operations) when a program
>crashes or is aborted.  The easy way to recover the contents is:
>	1. erase the zero-length file.
>	2. run chkdsk on your drive with the "lost" file
>	3. chkdsk will find "lost clusters" which are the contents
>	   of the file as written.
>	4. convert these to files (names like "file0000.chk" in the
>	   root directory.
>	5. if you find more than one of these, examine each one to see
>	   which one(s) you want - erase the others.
>	6.  rename the ones you want to keep.

Ahhh.  Erasing the file and *then* running CHKDSK.  I haven't done
this *after* I had deleted the file.  It looks elaborate enough to
probably work, so those with a similar problem in the future may wish
to try this approach.  I mentioned in my last posting about fearing to
use CHKDSK with my disk patitioned.

--------

Also, someone earlier suggested deleting the file and then undeleting
it with Norton Utilities.  This was close !  I deleted the file, and
used Norton to undelete it.  When I told it to find all the data
(search for data selection), it immediately returned saying "no
further data" or something.  When I told it to save the file, it said
to search for the data first.  Hmmm.  Checking for data clusters > 0 ??
I couldn't get my file of length 0 back !

Well, I decided to go ahead and play with the directory sectors.  I
undeleted the file myself (using Norton to display and change the
sector) by changing the E5 to the actual first letter of the filename.
Then I randomly chose 250,000 as the filesize, and entered that.
(I figured the Norton software would read clusters for the file until
a) the filesize is reached, *or* b) the end-of-file marker is hit.)

(I can't recall if I put the initial cluster in as well.  I had located
it beforehand, but don't remember if I put it in the dir table.)

I then deleted the file from DOS, reentered Norton, and undeleted it.
One permutation (not exiting between file size changes) caused the
file to read 250K, but an editor brought it to the actual 97K (after
copying it to my ramdisk).  I played with Norton some more, exiting
between file size writing, and Norton computed it to 97K when it
undeleted the file.

Whew !  So far, no effects on other files that I have found from choosing
the 250K initially.  This method is more cumbersome than the last reply
listed above. But I got away without using CHKDSK.

Side note: Procomm will update the directory whenever you do a
directory list (Alt-F).  This is why I couldn't replicate the problem
on Friday, because I kept 'checking' to see if anything was being
written.

Thanks to all of you who have replied (and will reply through the
ripple-effect).  I'm still open to everyone's Backup program
favorites; namely, Fastback vs. Backup Master.

-- 

:-- Paul
:
:UUCP:	...!{decuac, rlgvax, seismo, verdix}!vrdxhq!bisanabi