Fri 02 Jan 2015 05:22:49 PM UTC, comment #12:
Okay, pushed to the development branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/d8fd3842a507). Marking bug as fixed and closing report.
|
Fri 02 Jan 2015 01:41:13 PM UTC, comment #11:
Looks good to me - you going to push, or should I?
|
Fri 02 Jan 2015 05:59:51 AM UTC, comment #10:
I took a look at the patch and cleaned up a few things. If no prefix is specified the old tempnam would use the prefix "file" so I added that. I also simplified the loading of tempname.h to just a single extern since we are not LIBC and never will be. In do_get_temp_directory I segregated the cases in to Windows vs. UNIX so that the UNIX branch never needs to check the TEMP environment variable. I've uploaded the cset. It passes all tests for me.
(file #32746)
|
Thu 01 Jan 2015 04:15:40 PM UTC, comment #9:
New patch attached using gen_tempname
(file #32743)
|
Fri 26 Dec 2014 04:21:14 AM UTC, comment #8:
Linking bug to an earlier report of the same issue with some more discussion about using gnulib.
|
Thu 25 Dec 2014 04:32:09 PM UTC, comment #7:
Rather than write our own routines to re-perform the work of tempnam, I think it would be better to use whatever we can from gnulib.
One way would be to check for the appropriate environment variable and the dir arg being set, and in such a case use unsetenv temporarily before calling tempnam.
Another choice would be to use get_tempname from gnulib directly. See https://github.com/gagern/gnulib/blob/master/lib/tempname.h.
In this case we set up the template string with either P_tmpdir or the dir_arg if it is set and then call get_tempname.
|
Thu 25 Dec 2014 01:38:00 PM UTC, comment #6:
Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/eee9f111c164
|
Tue 23 Dec 2014 03:33:28 PM UTC, comment #5:
How about this (attached) which checks the final name if the path was modified and appends to the name if it exists to make it unique.
(file #32704)
|
Tue 23 Dec 2014 11:43:04 AM UTC, comment #4:
According to msdn [1]:
[1] http://msdn.microsoft.com/en-us/library/hs3e7355.aspx
|
Tue 23 Dec 2014 11:25:40 AM UTC, comment #3:
On my win7, 64 bit machine.
It isn't quite just doing an increment each time, but it's close.
|
Tue 23 Dec 2014 06:13:06 AM UTC, comment #2:
Well, I think it is wrong, but apparently an incrementing number is all that tempnam under Windows does.
|
Tue 23 Dec 2014 05:58:19 AM UTC, comment #1:
There seems to be something wrong with the tempnam function under Windows. Even without the modifications for bug #43844, the returned value should have 6 characters worth of randomness.
For example, on a Linux machine
What do repeated invocations of just tempname produce on Windows?
Is it just a numerically increasing filename?
|
Mon 22 Dec 2014 06:19:50 PM UTC, original submission:
Under windows, the temporary file naming is rather deterministic, and each time I run octave, I can see the sequence of file names used.
In part because of that, if specifying your own directory, the temporary name may already exist.
For example, if I have a directory c:\\temp\\oct-2.
On first call of tempname:
The fix for Bug 43844 [1] makes the function no longer check if it is/was a unique temporary name.
The Linux tempnam function provides a more random filename and so is less likely to already exist.
[1] https://savannah.gnu.org/bugs/?43844
|