bugGNU Octave - Bugs: bug #36688, tempname does not return a...


bug #36688: tempname does not return a sufficiently unique file name on windows

Submitted by:  None
Submitted on:  Tue 19 Jun 2012 10:44:00 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  dev
Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 06 Jan 2015 06:02:55 PM UTC, comment #6: 
John Donoghue <lostbard>
Project Member
Thu 21 Jun 2012 07:32:36 PM UTC, comment #5: 

It looks to me like the __stdio_gen_tempname function could be replaced by a combination of the __path_search adn __gen_tempname functions that are defined in the gnulib tempname.c file, but the __path_search function is not defined unless _LIBC is defined.  The __path_search function would be helpful in determining what tmp directory should be used to construct a template for the __gen_tempname function.  So I don't know why it is not provided by the gnulib module.  Or, hey, just make the gnulib tempname module provide a direct replacement for the tempname function...

John W. Eaton <jwe>
Project Administrator
Thu 21 Jun 2012 07:01:06 PM UTC, comment #4: 

For the sake of avoiding confusion, I'm not planning to work on this, but am happy to test any proposals under MacOS X.

Ben Abbott <bpabbott>
Project Member
Thu 21 Jun 2012 06:56:24 PM UTC, comment #3: 

The gnulib tempname module looks like it might provide a more random set of file names.  But I think we are still using the version of tempname.c that is in the liboctave directory instead of using the one from gnulib.

But the __gen_tempname function defined by the gnulib tempname module does not seem to have the same interface as the __stdio_gen_tempname function that we have in liboctave/tempname.c, and that is expected by the tempname.c function.

It would be great if someone could straighten this mess out.

John W. Eaton <jwe>
Project Administrator
Thu 21 Jun 2012 04:29:57 PM UTC, comment #2: 

For reference, here is some simple code and the results on a Linux platform.

for i = 1:10
> tempname ()
> endfor
ans = /tmp/oct-7zvpQC
ans = /tmp/oct-mIWsuN
ans = /tmp/oct-PY8w8X
ans = /tmp/oct-lgZBM8
ans = /tmp/oct-y3CHqj
ans = /tmp/oct-VBUN4t
ans = /tmp/oct-c8YUIE
ans = /tmp/oct-dtH2mP
ans = /tmp/oct-oP7a1Z
ans = /tmp/oct-cgkkFa

So the results are quite good for Linux.

However, my C library has the tmpnam () function which Windows may not.  Check what configure has found for your system by looking at the file config.h.  Here is one way to do so.

grep -i tempnam config.h

which, for me, returns

/* Define to 1 if you have the `tempnam' function. */
#define HAVE_TEMPNAM 1

Note that the code in tempname.c is protected by a '#ifdnef TEMPNAM' which means it is only used as a fallback when configure and Octave can't find better alternatives.

Rik <rik5>
Project Administrator
Tue 19 Jun 2012 11:49:19 PM UTC, comment #1: 

I've confirmed this behavior running 3.6.2 on Windows.

Looking through Octave's sources, it looks to me as if the tmpnam() function relies on gnulib for the file name. The source files involved are;

src/file-io.cc (DEFUNX ("tmpnam",...))
liboctave/file-ops.cc (octave_tempnam)

I believe the last two are from gnulib.

If memory serves me, we didn't use gnulib for the 3.2.x series.

If I'm reading the code correctly, the function which defines the file name does check for existing files. However, as I don't see how randomized names are produced for unix, I may be wrong.

Ben Abbott <bpabbott>
Project Member
Tue 19 Jun 2012 10:44:00 PM UTC, original submission:  

The function tempname on the windows build 3.6.1 returns file names like the following:


etc. with the number increasing on each subsequent call. This is ok, but if we are running two or more instances of octave they each begin counting from 1. This means there is a high risk of attempting to access the same files (especially if you expand this to many octave instances being launched and quit at random times to perform a parallel computing task).

It would be nice if tempname used the cpu time or something like this to produce a more randomised file name. This would also be more compatible with Matlab.

On linux (Scientific Linux 6.2) using Octave 3.2.4 the file name is more randomised, I can't test newer octave version on linux at the moment to see if this is still the case.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-01-06 lostbard StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2014-12-26 rik5 Dependencies- => bugs #43872 is dependent
    2014-03-11 mtmiller Dependencies- => bugs #41836 is dependent
    2014-01-19 mtmiller CategoryNone => Octave Function
    2012-06-19 bpabbott StatusNone => Confirmed
        Release3.6.1 => dev

    Back to the top

    Powered by Savane 3.5