bruschke@vax1.acs.udel.EDU (Michiel Bruschke) (08/30/90)
In article 2160 of alt.sources Marvin Kraska writes: > However, I have noticed that on the PC, lost clusters are reported >by "chkdsk" on the drive that the temporary file is placed. Sure >enough, the recovered file is elvis's temp. I glanced at the tmp.c >code, and didn't see anything obvious. I noticed exactly the same thing on my system. I compiled elvis using Quick-C. Elvis copies the tmp file to the new file, but then somehow improperly deletes the tmp files. It seems to do this with all tmp files it opens, cut buffers as well as regular tmp file. Will take a closer look at source to see if I can figure it out (probably over weekend). So if you use elvis be sure to run chkdsk /f afterwards. Mike Bruschke
tjr@cbnewsc.att.com (thomas.j.roberts) (08/30/90)
From article <6887@vax1.acs.udel.EDU>, by bruschke@vax1.acs.udel.EDU (Michiel Bruschke): > > In article 2160 of alt.sources Marvin Kraska writes: > >> However, I have noticed that on the PC, lost clusters are reported >>by "chkdsk" on the drive that the temporary file is placed. Sure >>enough, the recovered file is elvis's temp. I glanced at the tmp.c >>code, and didn't see anything obvious. This (aparently) happens only when you have text in named cut-buffers, and you switch files. MS-DOS cannot rename a file that is open. elvis does this in cut.c, function cutswitch(). This BUG has been in MS-DOS since version 2.0, and is not fixed in 3.3; I suspect it would be difficult to fix in any version of MS-DOS. This fix (Turbo C) works for me: In file cut.c, replace the line [within #ifdef TOS || MSDOS] rename(tmpname, cutname); with: #if MSDOS /* TJR Fix - part 1 of 2 (MS-DOS cannot rename an open file) */ close(fd), close(tmpfd); tmpfd = -1; #endif rename(tmpname, cutname); #if MSDOS /* TJR Fix - part 2 of 2 */ j = open(cutname, O_RDWR | O_BINARY); if(j != fd) { dup2(j,fd); close(j); } #endif elvis seems to be a GREAT service provided by Steve Kirkendall - Thanks! I have already sent this fix to him. Good luck. Tom Roberts att!ihlpl!tjrob
gened@gssc.UUCP (Gene Daniel) (08/31/90)
In article <6887@vax1.acs.udel.EDU> bruschke@vax1.udel.edu (Michiel Bruschke) writes: > >In article 2160 of alt.sources Marvin Kraska writes: > >> However, I have noticed that on the PC, lost clusters are reported >>by "chkdsk" on the drive that the temporary file is placed. Sure >>enough, the recovered file is elvis's temp. I glanced at the tmp.c >>code, and didn't see anything obvious. > >I noticed exactly the same thing on my system. I compiled elvis >using Quick-C. Elvis copies the tmp file to the new file, but >then somehow improperly deletes the tmp files. It seems to do >this with all tmp files it opens, cut buffers as well as regular >tmp file. Will take a closer look at source to see if I can figure >it out (probably over weekend). > >So if you use elvis be sure to run chkdsk /f afterwards. > >Mike Bruschke I also found this. I found it both with MSC and with Zortech so it wasn't the compiler. Some time back I discovered that deleting an open file causes unallocated clusters. This is apparently the cause of the lost clusters from Elvis. I was able to fix it by placeing the following two lines just before the rename() call in the routine cutswitch() in the file cut.c: close(tmpfd); tmpfd = -1; The only other access to this file is after it is renamed to a cut buffer file and this is done through a dup'ed file descriptor. I have sent this information to Steve Kirkendall, the author of Elvis, so the "official" patch should soon be on it's way. I have been using Elvis with this fix and named cut buffers between files seem to be working alright and no more unallocated clusters. -- Gene Daniel | gened@gss.com Graphic Software Systems, Inc. | or P.O. Box 4900 | ..!tektronix!sequent!gssc!gened Beaverton, Oregon 97005-7161 |