Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!noao!arizona!naucse!jdc
From: jdc@naucse.UUCP (John Campbell)
Newsgroups: comp.lang.c
Subject: Re: Bug in MS C unlink() ?
Message-ID: <1205@naucse.UUCP>
Date: 13 Mar 89 20:32:40 GMT
References: <89Mar13.100742est.10755@ephemeral.ai.toronto.edu>
Organization: Northern Arizona University, Flagstaff, AZ
Lines: 40

From article <89Mar13.100742est.10755@ephemeral.ai.toronto.edu>, by bradb@ai.toronto.edu (Brad Brown):
> In article <1032@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes:
>>I ran into a nasty problem with unlink() in Microsoft C's unlink()
>>call (MS C 4.0 and 5.1).  It seems that if one unlinks an *open*
>>file on a hard disk, the result is lost clusters!   the unlink()
>>call itself returns 0.
>>
> 
> This makes sense, given how the operating system works.  (That's not to say
> that PC users (like myself) would not be much better off with a *real* 
> operating system :-)  I don't think this is a bug, just an evilness on the
> part of the operating system.
> 
> The problem occurs for the following reason:  DOS is not smart enough to
> hold an unlink()ed file open until it is close()d, so the file just
> 
> Unfortunately, compatability constraints and general dumbness of the 
> operating system preclude an easy answer.

If you change the above from "DOS is not smart..." to "VMS is not smart..."
you have a common VMS situation as well.  One difference, however, is that
Digital doesn't pretend to provide an unlink() as part of the 'C' RTL under
VMS.  This is good; it forces the programmer to look at what is really
happening in the code.  Is unlink() just a delete(), or is unlink() providing
a temporary file that will go away at the close?

VMS also has the strange habit of really closing stdout if you dup() and
then close() one of the file descriptors.  This problem (which is sort
of rare, but did happen to me in gnuplot) is really a bug in my way
of thinking.

Oh well, I just followed up to suggest that MSC and PC implementors shouldn't
provide an unlink() that is not compatible with the unix counter part.  And
VMS shouldn't provide dup() unless it can properly decrement and close()
descriptors.  Also, I have wished, at times, that unix programmers would 
unlink() since this is a very operating specific idea.
-- 
	John Campbell               ...!arizona!naucse!jdc
                                    CAMPBELL@NAUVAX.bitnet
	unix?  Sure send me a dozen, all different colors.