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