[Mingw-notify] [ mingw-Bugs-1048593 ] tmpfile() replacement

[SourceForge.net <no...@so...>]

Bugs item #1048593, was opened at 2004-10-17 10:35
Message generated for change (Comment added) made by brandysb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1048593&group_id=2435

Category: mingw runtime
Group: Feature requests
Status: Open
Resolution: None
Priority: 5
Submitted By: Boguslaw (brandysb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tmpfile() replacement

Initial Comment:
MAX_TMP 32767 Bug report (Closed) for mingw-runtime no.
1047975

If tmpfile() limitation to 32767 temporary files in
process and this is related to MSVC runtime please
consider replacement for this function. This could be
simple, fast and efficient like this :

FILE * tmpfile(void)
 {
    char filename[MAX_PATH];
    FILE *f;
 
    GetTempFileName(".","temp",0,filename);
    f = fopen(filename,"w+bTD");
    return f;
 }


Works very well.


Best Regards
Bogusław Brandys

----------------------------------------------------------------------

>Comment By: Boguslaw (brandysb)
Date: 2004-10-17 21:47

Message:
Logged In: YES 
user_id=1092450

Well  I could not test it on some NT/XP Pro , but the
modified function just creates temporary files in current
user temp directory so no race conditions exists.

I'm also quite sure that there is no gap between getting the
temporary name and creating temporary file (like would be if
tmpname will be used) becouse GetTempFileName is atomic and
CREATE unique file then closing it.After that file exists
and is opened by fclose with special flag which causes it to
be delete on close/exit.
Of course that is no prevent for malicious code to write
into the file in time BEETWEN GetTempFileName and fopen, but
this is hardly to avoid .



----------------------------------------------------------------------

Comment By: Boguslaw (brandysb)
Date: 2004-10-17 21:39

Message:
Logged In: YES 
user_id=1092450

Sorry, i dont understand why my response is goint the first
on the list not under the other comments ;-(

But, I must say that this function DOES properly close file
when fclose is used or application is terminated (well
sometimes do not on crash) This is why "D" option is used
according to MSDN.
If someone , preferably C runtime Guru could say if this is
mt-safe would be better, but I quite sure that there is now
(after add GetTempPath)  better then existing tmfile()
implementation in mingw runtime.

----------------------------------------------------------------------

Comment By: Boguslaw (brandysb)
Date: 2004-10-17 21:32

Message:
Logged In: YES 
user_id=1092450

Modified proposition:

FILE * tmpfile(void)
 {
    char temppath[MAX_PATH]; 
    char filename[MAX_PATH];
    FILE *f;
    int i;
    
    i = GetTempPath(MAX_PATH,temppath);
    if ((i==0) || (i > MAX_PATH)) return NULL;
    if (GetTempFileName(temppath,"tmp",0,filename)==0)
return NULL;
    f = fopen(filename,"w+bTD");
    return f;
 }

Regarding MSDN documentation tmpfile() VC++ implementation 
is far from complete. I didn't find any errno setting mentioned
in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_tmpfile.asp
- only NULL is returned in case of error.

I'm not going to send a "ready to go" implementation (in
that case I should then rather send a patch) but my example
is really based on two functions , and I think that both are
very known.
I tested race conditions and seems no one exists  even if
the same prefix for temporary files is given . Someone could
extend this function to set always unique prefix based on
rand or time value but it seems not necessary becouse
GetTempFileName  is internally checking for file presence.
If somebody could check permissions behaviour I would be
glad also. i checked it only on read-only system and just
return NULL (proper behaviour)

Option T means 	_O_SHORTLIVED and could be removed in case
of security (file is maintained fully in memory if available)

Check also
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/gettempfilename.asp


Regards
Boguslaw Brandys

----------------------------------------------------------------------

Comment By: Aaron W. LaFramboise (aaronwl)
Date: 2004-10-17 20:28

Message:
Logged In: YES 
user_id=1040098

I'd say that "simple, fast, and efficient" is something of a
myth in generic library code that must cope with diverse
situations that its creator may not have foreseen.  There
are a few problems here:

The return values for both functions need to be checked, as
both of them can fail.  Sometimes this can mean a security
problem (some versions of mkstemp() will warn about this
situation), but on Windows, as far as I know all versions
that enforce user permissions also give each user a
different temp dir.  I could still see potiential for abuse
coming from two programs running as the same user being
manipulated in some way by an adversary.

"." maybe should be GetTempPath().  I noticed that msvcrt
tmpfile() just creates the files in c:\, which is a little
odd.  Some parts of the documentation imply that it might
create files in the pwd.  It seems best to use TEMP or TMP
though, as GetTempPath() does.

This implementation isn't actually standards-conforming,
because it doesn't remove the files automatically on close
or on program termination (the standard permits either). 
However, MSVC docs are more strict, stating that the file is
removed on close.  I beleive this can be accomplished by
manipulating the iobuf directly to save the filename.

_rmtmp() compatibility with the new tmpfile() would also
need to be confirmed.

msvc probably also is passing _O_TEMPORARY to _open(), which
might cause it to pass FILE_ATTRIBUTE_TEMPORARY to
CreateFile().  This is impossible to do through fopen(). 
The situation here needs to be investigated.

Multithreading needs to be examined.  This function will
probably need to lock a mutex: the gap between fopen() and
setting iobuf attributes might cause problems for certain
functions, such as _rmtmp().

There might be other things.  This is just what popped into
my head.  In any case, any replacing of a function needs to
be thought about very carefully.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1048593&group_id=2435