The value of FILE_DELETE_ON_CLOSE, which is defined as 0x00001000 in winnt.h, does not equal constant (0x04000000), defined in MSDN page http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
So, any application, built with MinGW headers, which is use FILE_DELETE_ON_CLOSE for file creation, will have wrong behaviour.
Thanks for the heads-up; that doesn't seem to offer any clue as to what effect
0x00001000might have, so clearly, we need to correct this. That said ...FWIW, if you adopt a more pragmatically portable coding style, rather than blindly kowtowing to Microsoft's lock-in doctrine, the following example:
when compiled and linked with the mkstemp implementation I provided in response to [#2003], does exhibit correct behaviour, as may be seen when running in an MSYS shell session:
(Notice that the temporary file continues to exist, after initially writing to it, for the duration of the
Sleep(60000)in the executable, then "auto-magically" disappears when the file is closed, so terminating the shell loop). I realize that this isn't strictly relevant, since it doesn't rely on theFILE_DELETE_ON_CLOSEdefinition in MinGW.org headers -- open(), as called within__mingw_mkstemp()with theO_TEMPORARYflag set, appears to DTRT regardless; just thought I'd point it out, as a plug for the advantages of portable coding.Related
Issues: #2003
I know this 6+ years old, but I've just stumbled on it again; clearly, no action was ever taken, and since Earnie is no longer playing an active rôle, I decided to follow up myself.
Unfortunately, the original report appears to misrepresent fact — the cited MSDN reference does not stipulate a value of
0x4000000forFILE_DELETE_ON_CLOSE; this is the documented value forFILE_FLAG_DELETE_ON_CLOSE... a different entity, which does appear to be correctly defined, (albeit irrationally as an equivalent decimal value), in<winbase.h>.Since I can find no Microsoft documentation reference, which states an appropriate value for
FILE_DELETE_ON_CLOSE, I cannot just assume that it should be0x4000000, so I'm closing this, with no further action proposed.