aland@infmx.UUCP (Dr. Scump) (03/09/89)
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.
Question: is this legal? (key word here is LEGAL, I didn't say SMART)
UNIX, of course, handles this just fine: the file disappears normally
when it is no longer open in any process.
The documentation does not state any restrictions on unlinking
open files. (File was opened for writing with a regular fopen()).
Known problem? Known limitation? DOS 3.3 bug? Did yesterday's
solar eclipse have anything to do with it? (I did verify it in 4.0
and 5.1 and on 3 different machines).
Thanks in advance,
Alan Denney
--
Alan S. Denney @ Informix Software, Inc.
{pyramid|uunet}!infmx!aland "I want to live!
-------------------------------------------- as an honest man,
Disclaimer: These opinions are mine alone. to get all I deserve
If I am caught or killed, the secretary and to give all I can."
will disavow any knowledge of my actions. - S. Vegabradb@ai.toronto.edu (Brad Brown) (03/13/89)
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 dissapears from the FAT and directory. Your program, however, still has what it thinks is an open file handle that includes some FAT information. When you close the file or terminate the program, the FAT information in the file handle is written out but THE DIRECTORY IS NOT UPDATED, which is eq. to producing lost clusters (since these clusters are not part of any file and are not part of the free cluster chain...) Unfortunately, compatability constraints and general dumbness of the operating system preclude an easy answer. (-: Brad Brown :-) bradb@ai.toronto.edu
jdc@naucse.UUCP (John Campbell) (03/14/89)
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.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/14/89)
In article <1205@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes: >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. ... >Also, I have wished, at times, that unix programmers would >unlink() since this is a very operating specific idea. The pANS requires the C environment to provide remove(), which is similar to the UNIX unlink() except that there are no portable promises made for removing an active file, etc. Removing a file is hardly operating-system specific; it's the notion that I/O can still be done to a removed file if you still have a handle to it that's OS-specific.
jls@killer.Dallas.TX.US (Jerome Schneider) (03/16/89)
In article <9849@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <1205@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes: > >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. ... > >..... MSC 5.x provides the atexit() mechanism for stashing up to 32 function pointers to be called at exit (and _exit). This would seem the likely spot to process any unlinks() from open file handles. Agreed, it does not address the question of what I/O to an unlinked but open file really means. -- Jerome Schneider UUCP: killer!jls.DALLAS.TX.US (guest account) Aspen Technology Group Ft. Collins, CO Voice: (303) 484-8466