Menu

#2227 winnt.h: #define for FILE_DELETE_ON_CLOSE is wrong.

WSL
closed
None
Bug
wont-fix
No_Documentation
False
2021-01-25
2014-07-22
_bg_
No

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.

Discussion

  • Keith Marshall

    Keith Marshall - 2014-07-23

    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

    Thanks for the heads-up; that doesn't seem to offer any clue as to what effect 0x00001000 might have, so clearly, we need to correct this. That said ...

    So, any application, built with MinGW headers, which is use FILE_DELETE_ON_CLOSE for file creation, will have wrong behaviour.

    FWIW, if you adopt a more pragmatically portable coding style, rather than blindly kowtowing to Microsoft's lock-in doctrine, the following example:

    #define WIN32_LEAN_AND_MEAN
    #define _POSIX_C_SOURCE 200112L
    
    #include <windows.h>
    
    #include <stdio.h>
    #include <stdlib.h>
    
    /* The following, (or some alternately filtered variant thereof),
    
     * has not (yet) been incorporated into stdlib.h
     */
    #if _POSIX_C_SOURCE >= 200112L
    
    extern int __mingw_mkstemp( int, char * );
    extern char *mkdtemp( char * );
    
    #define MKSTEMP_INVOKE       0
    #define MKSTEMP_DEFAULT      O_CREAT | O_EXCL | O_RDWR
    #define MKSTEMP_SETMODE(M) __mingw_mkstemp( MKSTEMP_DEFAULT | (M), NULL )
    
    _CRTALIAS int mkstemp( char *template )
    {
      return __mingw_mkstemp( MKSTEMP_INVOKE, template );
    }
    #endif
    
    #include <string.h>
    #include <unistd.h>
    #include <fcntl.h>
    
    int main()
    {
      int fd;
      char template[] = "./tmpfileXXXXXX";
      MKSTEMP_SETMODE( O_TEMPORARY );
      if( (fd = mkstemp( template )) >= 0 )
      {
        write( fd, template, strlen( template ) );
        printf( "file %s written\n", template );
        Sleep( 60000 );
        close( fd );
      }
      return 0;
    }
    

    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:

    $ ./mkstemp-example.exe &
    [1] 1744
    file ./tmpfilehsjrdg written
    
    $ while ls tmp*; do sleep 2; done
    tmpfilehsjrdg
    tmpfilehsjrdg
    ...
    tmpfilehsjrdg
    [1]+  Done                    ./mkstemp-example.exe
    ls: tmp*: No such file or directory
    

    (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 the FILE_DELETE_ON_CLOSE definition in MinGW.org headers -- open(), as called within __mingw_mkstemp() with the O_TEMPORARY flag set, appears to DTRT regardless; just thought I'd point it out, as a plug for the advantages of portable coding.

     

    Related

    Issues: #2003

  • Keith Marshall

    Keith Marshall - 2014-07-23
    • status: unread --> assigned
    • assigned_to: Earnie Boyd
    • Group: MSYS --> WSL
     
  • Keith Marshall

    Keith Marshall - 2021-01-25

    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 0x4000000 for FILE_DELETE_ON_CLOSE; this is the documented value for FILE_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 be 0x4000000, so I'm closing this, with no further action proposed.

     
  • Keith Marshall

    Keith Marshall - 2021-01-25
    • status: assigned --> closed
    • Resolution: none --> wont-fix
    • Category: Unknown --> No_Documentation
     
MongoDB Logo MongoDB