[Tcl-bugs] [ tcl-Bugs-878333 ] workaround for buggy(??) mkstemp() on IRIX systems

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

Bugs item #878333, was opened at 2004-01-16 15:25
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=878333&group_id=10894

Category: 36. File System
Group: current: 8.4.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerd Sussner (sussner)
Assigned to: Joe English (jenglish)
Summary: workaround for buggy(??) mkstemp() on IRIX systems

Initial Comment:
This bug concerns only IRIX systems (6.5.19m) so far.

Using a tclkit with included dynamic libraries results
in the following
error message when loading a second dynamic library
from the vfs:

> tclkit-irix
% package require Itcl
3.3
% package require Tk
couldn't find procedure Tk_Init
%

I tracked it down to the temporary filename create
mkstemp() in
TclpTempFileName() in tclUnixPipe.c. mkstemp() always
uses the
same filename, but keeps the content of the first file
copied into
it. I.e. a second call of TclCrossFilesystemCopy()
means that the
content of the first call is still present causing
TclpFindSymbol() not
to find the <EXT>_Init() procedure.
Adding a counter to the temporary filename solves this
problem. I
submit a patch as well.

hope that helps

gerd

ps: i just wonder whether i am the first one, using
tclkits under IRIX.

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

>Comment By: Donal K. Fellows (dkf)
Date: 2004-02-23 11:50

Message:
Logged In: YES 
user_id=79902

AIUI, what we need to do is to get the temporary file name
back and at the same time have the temporary file open for
modification (keeping it open stops some security-related
race conditions).

BTW, I think I do not agree with removing TclpTempFileName()
(though altering its API sounds like a good thing) since it
might well end up being useful elsewhere in the core in the
future (e.g. for loading Win icons and cursors from starkits.)

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

Comment By: Vince Darley (vincentdarley)
Date: 2004-02-23 11:11

Message:
Logged In: YES 
user_id=32170

It looks as if Tcl_FSLoadFile doesn't mind if the return
value of TclpTempFileName exists or not, so perhaps that
function can be changed not to delete the file?  Or it
should be changed to ensure it always creates a new empty
name with an empty file?

I don't quite understand what Joe is suggesting...  How can
we get rid of TclpTempFileName()?  It's needed by
Tcl_FSLoadFile...  I can understand that we might want to
fix TclpTempFileName() and/or adjust how it is called, what
it returns, but _remove_ it !?!?



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

Comment By: Joe English (jenglish)
Date: 2004-02-20 23:24

Message:
Logged In: YES 
user_id=68433

It looks like Tcl_FSLoadFile() is the only caller of
TclpTempFileName() in the core.  This should be fixed, and
TclpTempFileName() removed.  Back to you, Vince!

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

Comment By: Joe English (jenglish)
Date: 2004-02-20 23:10

Message:
Logged In: YES 
user_id=68433

This looks more like a bug in TclpTempFileName() -- it calls
mkstemp() to generate a temporary file, but then deletes the
file and closes the file descriptor.  So a subsequent call
to mkstemp() can use the same filename, as it's still unique.

As a matter of fact, TclpTempFileName() is Broken As
Designed: there is no safe way to generate a temporary file
name without creating the file at the same time; otherwise
you suffer a race condition.

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

Comment By: Donal K. Fellows (dkf)
Date: 2004-01-17 01:10

Message:
Logged In: YES 
user_id=79902

Assigning to myself because I've got access to IRIX systems

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

Comment By: Vince Darley (vincentdarley)
Date: 2004-01-17 00:16

Message:
Logged In: YES 
user_id=32170

Assigned to someone who knows more about Unix ;-)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=878333&group_id=10894