Path: utzoo!utgpu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!axion!delluk!tim From: tim@delluk.uucp (Tim Wright) Newsgroups: alt.sources Subject: Re: ELVIS WARNING - LOST CLUSTERS ON PC's Message-ID: Date: 31 Aug 90 15:24:05 GMT References: <1990Aug29.150748.14752@cbnewsc.att.com> <689@aut.UUCP> Sender: usenet@delluk.uucp (Usenet posting login) Organization: Dell Computer Corp., Bracknell, UK Lines: 57 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).