bisanabi@vrdxhq.UUCP (Paul Paloski) (07/23/87)
Five days ago I was using Procomm to communicate with a BBS. I had a
log file open to capture all data being displayed on my terminal.
After about an hour of scrolling messages (I was going to read and
sort them later), I promptly logged out and powered the machine off
without exiting Procomm. It immediately dawned on me that the FAT may
not have been updated. I held my breath and turned my AT on again.
Sure enough, the file size was listed as 0 bytes ! Argghhh! I didn't
want to waste another hour tying up the BBS, so I spent 2 hours trying
to figure a way to make Norton Utilities recover the data, and another
hour rummaging through some text books. I decided against trying to
write a program that I would never use again, and ended up calling the
BBS back.
Well, last night I did it again !! Guess my mind is a little slow at
3 A.M. when I get up at 6:00. Does anyone have a program that will
start at a given sector, follow the pointers around, and group them
into a file ?? I can figure out which sector the data begins at, and
know the actual text that begins and ends the session.
Preference : 1) Give me the name/location of a PD program that does.
2) Give me the name/location of a commercial program that does.
3) Can someone post/mail me a program that does this ?
I'm going to wait a couple days before I do anything that will reuse
those sectors. Mail me directly and I will post a summary.
--
:-- Paul
:
:UUCP: ...!{decuac, rlgvax, seismo, verdix}!vrdxhq!bisanabibrown@nicmad.UUCP (Mr. Video) (07/24/87)
In article <4142@vrdxhq.UUCP> bisanabi@vrdxhq.UUCP (Paul Paloski) writes:
[... discusses problems with 0 length files ...]
Norton's Utilities Advanced Addition will allow you to be able to easily
rechain the FAT and fix up the directory. Once you figure out where
everything is you can fix up everything real easy.
--
harvard-\ ihnp4--\ BITNET: brown%nicmad.UUCP@spool.wisc.edu
Mr. Video seismo!uwvax.......!nicmad!brown
rutgers-/ decvax--/
terminus-/bisanabi@vrdxhq.UUCP (Paul Paloski) (07/24/87)
Thanks to those who have responded. Several people have given me similar possible solutions which I shall list and explain my problems. I will try to be more specific this time. First, I am using an IMS-286 AT-Clone, with a 70 Meg hard disk. I am running SpeedStor, which has allowed me to partition this disk into 5 logical drives (C:, D:, E:, F:, and G:). Also, I tried to replicate the problem today on a true IBM PC/AT at work with just the one partition, and Procomm's log file was updated regularly. I could *not* duplicate my error ?!? They were both version 2.4.2, so is it the Clone (using Phoenix BIOS), bad copy of Procomm (I'll replace my copy with the one I just tried), or is the SpeedStor partitioning software being weird ? I have a RAM Disk, but I brought one up during my test and it still worked fine. >From: seismo!ut-sally!ghostwheel!dan (Dan Frank) > I thought CHKDSK did something like that. If you run it on a disk >that has orphan chains floating around, it will ask you something like, >From: seismo!ncrcan!root () > Try CHKDSK/F. It should be able to group all the sectors that >constitute the file into one file, typically named FILE000?.CHK. > I thought I had been warned against using CHKDSK/F because of the partitioning and/or the SpeedStor software itself. Someone today told me I probably do *not* want to do this with partitions. ------------------------------------------------------------------------------ Someone mentioned that they had done a similar thing by altering both the BOOT sector and FAT table, giving me references in Advanced MS-DOS. I checked Norton's book, and fiddled with the Norton utilities, enough to have familiarized myself with the BOOT and FAT sector layouts. >From: seismo!ncrcan!root () (Brian Onn) > If this doesn't work, try deleting the zero length file and then >undelete it with Norton Utilities. No, this will not work. When a file is deleted, the only thing that changes is the byte representing the first character of the filename. (Actually, this may work. The FAT does need to be updated some how to represent the cluster chain as available. Hmmm.) >From: Gordon W. Ross <seismo!ll-xn!linus!gwr> > >The Norton Utilities are supposed to allow you to fix this, though I'm >not an expert on their use. > >Another possibility is to use lowly DEBUG to set the file size field >in the directory entry which shows zero length, and then do a DOS copy >of the file to another device. You would have to guess at the file size. There is no obvious command for doing this, unless the delete/undelete mentioned by Brian above works. However, both Norton Utilities and DEBUG can allow me to alter the BOOT and FAT sectors by hand, but I'd hate to make another error and lose 55 Meg of data. Guess I should buy myself a backup program, back everything up, and then 'play' a little bit. Any preferences between Backup Master and Fastback? -- :-- Paul : :UUCP: ...!{decuac, rlgvax, seismo, verdix}!vrdxhq!bisanabi
philip@amdcad.AMD.COM (Philip Freidin) (07/24/87)
In article <4142@vrdxhq.UUCP> bisanabi@vrdxhq.UUCP (Paul Paloski) writes: > >Five days ago I was using Procomm to communicate with a BBS. I had a >log file open to capture all data being displayed on my terminal. >After about an hour of scrolling messages (I was going to read and >sort them later), I promptly logged out and powered the machine off >without exiting Procomm. It immediately dawned on me that the FAT may >not have been updated. I held my breath and turned my AT on again. >Sure enough, the file size was listed as 0 bytes ! Argghhh! I didn't > .... more assorted descriptions of computer abuse..... I too have done this, and at least for me, I found a wonderful program to dig me out! chkdsk /f This will let you recover most of what was sent (maybe even all). Hope this helps. Philip Freidin @ AMD SUNYVALE on {favorite path!amdcad!philip) Section Manager of Product Planning for Microprogrammable Processors (you know.... all that 2900 stuff...) "We Plan Products; not lunches" (a quote from a group that has been standing around for an hour trying to decide where to go for ZemZemZ
bisanabi@vrdxhq.UUCP (Paul Paloski) (07/25/87)
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
bob@cald80.UUCP (bob) (07/26/87)
I met this problem with another program I was working on a while back. What I found out was the program was opening the file for writing and then just buffering all of the data until it finished and then wrote it all out. This is necessitated in communications programs 'cuz as I recall, a disk interrupt is a higher priority than an rs232 interrupt and if all of the data doesn't get out or you take a soft error, you start losing bytes on the com line (the silly sucker don't got no buffering). The key here is DON'T turn off the computer while inside of a program. This is bad medicine in any world or universe. --- Thinking quickly, the IBM System Jock # Bob Meyer uttered an incantation in EBCDIC and made # Calspan Advanced Tech. Center the sign of the Terminated Fork. # seismo!kitty!sunybcs!cald80!bob The UNIX Guru only smiled and trapped # decvax!sunybcs!cald80!bob him in a recursive SED script.