tjr@cbnewsc.att.com (thomas.j.roberts) (08/29/90)
Following up to my previous posting on successfully building elvis: BEWARE! elvis is NOT cleaning up properly - it leaves LOST CLUSTERS on the temp disk. In my case this is a RAMDISK, and I did not check it after initially playing with elvis. elvis appears to work fine - I have used most of its commands, and it appears to be a VERY faithful clone of vi. I have no idea why it creates lost clusters in the temp disk, but that makes it HIGHLY SUSPECT. Others have reported similar problems using Quick C (I used Turbo C). Good Luck! Tom Roberts att!ihlpl!tjrob
nbladt@aut.UUCP (Norbert Bladt) (08/31/90)
tjr@cbnewsc.att.com (thomas.j.roberts) writes: >Following up to my previous posting on successfully building elvis: >BEWARE! elvis is NOT cleaning up properly - it leaves LOST CLUSTERS >on the temp disk. In my case this is a RAMDISK, and I did not check >it after initially playing with elvis. elvis appears to work fine - >I have used most of its commands, and it appears to be a VERY faithful >clone of vi. I have no idea why it creates lost clusters in the >temp disk, but that makes it HIGHLY SUSPECT. Others have reported >similar problems using Quick C (I used Turbo C). Good Luck! I had the same problem with a program ported from UNIX to MS-DOS. On UNIX (every flavour) it is possible to do the following (this may not be correct on UNIX, just to give you the idea what happens, no runtime checks included): char *TmpFileName, mktemp(); FILE TmpFile, fopen(); /* Create a unique name for temp. file */ TmpFileName = mktemp ("/tmp/pipapoXXXXXX"); /* open temp. file */ TmpFile = fopen (TmpFileName, "r+"); unlink (TmpFileName); /* delete temporary file. However, it is NOT deleted, because it has been opened by an application, i.e. this program ! */ /* Do the usual fread and fwrite operations here */ exit(); /* this will close and delete the temporary file */ If you do this on MS-DOS it will create lost clusters. On VMS it simply doesn't work (error reported by unlink). If you ignore the error code of the unlink (which most programs do :-( ) the temporary file is still existing after your application did exit. Since it is the temp disk you are having problems with, this rang a bell in me. Perhaps this part of the code is wrong in that way. I had a lot of problems with this programming style on MS-DOS and VMS. I have saved the elvis code but did not yet take a look at it. My comments are just a guess, though. >Tom Roberts Norbert Bladt. -- Please use this path as return address. DON'T USE THE RETURN PATH IN THE HEADER Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland Phone: +41 31 52 92 14 EMail: ..!uunet!mcsun!chx400!hslrswi!bladt
tim@delluk.uucp (Tim Wright) (08/31/90)
In <689@aut.UUCP> nbladt@aut.UUCP (Norbert Bladt) writes: >tjr@cbnewsc.att.com (thomas.j.roberts) writes: >>Following up to my previous posting on successfully building elvis: >>BEWARE! elvis is NOT cleaning up properly - it leaves LOST CLUSTERS >>on the temp disk. ... >I had the same problem with a program ported from UNIX to MS-DOS. >On UNIX (every flavour) it is possible to do the following (this >may not be correct on UNIX, just to give you the idea what happens, >no runtime checks included): > char *TmpFileName, mktemp(); > FILE TmpFile, fopen(); > /* Create a unique name for temp. file */ > TmpFileName = mktemp ("/tmp/pipapoXXXXXX"); > /* open temp. file */ > TmpFile = fopen (TmpFileName, "r+"); > unlink (TmpFileName); /* delete temporary file. > However, it is NOT deleted, > because it has been opened by > an application, i.e. this program ! > */ > /* Do the usual fread and fwrite operations here */ > exit(); /* this will close and delete the temporary file */ >If you do this on MS-DOS it will create lost clusters. >On VMS it simply doesn't work (error reported by unlink). >If you ignore the error code of the unlink (which most programs do :-( ) >the temporary file is still existing after your application did exit. >Since it is the temp disk you are having problems with, this rang a bell >in me. This style of programming is *perfectly* valid under UNIX. It is part of the UNIX filesystem semantics and is a good way of creating a temporary file that nobody can mess up (excepting race conditions), even without the BSD-style protected tmp directories. It also avoids leaving the temporary file around in the case of the process receiving a kill -9. However, as you noted, this causes problems elsewhere (although what DOS does just shows how poor DOS is). NFS has a special work around for this case, since it is used in other UNIX code, and cannot be properly handled by a truly stateless server. I'm sure it will be helpful to people that to know where the problem lies. Thanks, Tim -- Tim Wright, Unix Support | Email: ...!ukc!delluk!tim Dell Computer Corp. (UK), Bracknell | (pending domain registration).
strobl@gmdzi.UUCP (Wolfgang Strobl) (09/01/90)
tim@delluk.uucp (Tim Wright) writes: >In <689@aut.UUCP> nbladt@aut.UUCP (Norbert Bladt) writes: >>tjr@cbnewsc.att.com (thomas.j.roberts) writes: >>>Following up to my previous posting on successfully building elvis: (Discussion about temporary files, lost clusters etc deleted) >This style of programming is *perfectly* valid under UNIX. It is part >of the UNIX filesystem semantics and is a good way of creating a >temporary file that nobody can mess up (excepting race conditions), >even without the BSD-style protected tmp directories. It also avoids >leaving the temporary file around in the case of the process >receiving a kill -9. However, as you noted, this causes problems >elsewhere (although what DOS does just shows how poor DOS is). NFS has A really perfect argument. MSDOS filesystem semantics are different from Unix filesystem semantics. This shows how poor DOS is. Oh well... Wolfgang Strobl #include <std.disclaimer.hpp>
hp@vmars.tuwien.ac.at (Peter Holzer) (09/03/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >A really perfect argument. MSDOS filesystem semantics are different from >Unix filesystem semantics. This shows how poor DOS is. Oh well... If the filesystem semantics of MSDOS mean that you can remove (or rename) an open file and thereby corrupt your filesystem, that DOES show how poor DOS is, IMHO. If DOS is not able to defer the removal of an open file until the file is closed, it should not remove the file and return an error. Lost clusters are not dangerous, but having your disk slowly filled with them is at least inconvenient. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technische Universitaet Wien | as evolution | | | | | hp@vmars.tuwien.ac.at | in action! | | __/ | ...!uunet!mcsun!tuvie!vmars!hp | Tony Rand |
bbs@HANKEL.RUTGERS.EDU (Trashy) (09/04/90)
In article <1790@tuvie> hp@vmars.tuwien.ac.at (Peter Holzer) writes: ]strobl@gmdzi.UUCP (Wolfgang Strobl) writes: ]>A really perfect argument. MSDOS filesystem semantics are different from ]>Unix filesystem semantics. This shows how poor DOS is. Oh well... ] ]If the filesystem semantics of MSDOS mean that you can remove (or rename) ]an open file and thereby corrupt your filesystem, that DOES show how poor ]DOS is, IMHO. ] ]If DOS is not able to defer the removal of an open file until the file is ]closed, it should not remove the file and return an error. Lost clusters ]are not dangerous, but having your disk slowly filled with them is at least ]inconvenient. This brings up a general point about the design of system services and library software: make them _robust_! If you are writing a subroutine for some particular application, you can afford to leave it with some holes that you know the rest of the program is going to work around, but as soon as your routine is meant for general application, then any hole represents the potential for a plethora of bugged programs. Why leave that potential in there? MSDOS blows it big with the `rename' service call. If _I_ had written that I'd be embarrassed. -- Barry Schwartz bbs@hankel.rutgers.edu mnetor!dciem!nrcaer!alzabo!trashman@uunet.uu.net