ELVIS WARNING - LOST CLUSTERS ON PC's

[Tim Wright]

In <689 at aut.UUCP> nbladt at aut.UUCP (Norbert Bladt) writes:

>tjr at 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).