Re: temporary files under win32

[Charles Greathouse <charles.greathouse@case.edu>]

I have had problems with MPQS temp files on Windows, but only with
very large factorizations. I try to do the large ones on Linux (or,
better, with yafu).

> There are some... c:\temp, c:\windows\temp are frequently present...

The system variable %tmp% has the correct location. For me it is

C:\Users\owner\AppData\Local\Temp

on my work machine -- not something you would have guessed.

Charles Greathouse
Analyst/Programmer
Case Western Reserve University

On Fri, Oct 19, 2012 at 8:05 AM, Loïc Grenié <loic.grenie@gmail.com> wrote:
> 2012/10/19 Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
>> On Fri, Oct 19, 2012 at 10:49:28AM +0200, Loïc Grenié wrote:
>>> 2012/10/19 Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
>>>
>>> > The second is that there is a race condition of some sort.
>>> > If you create 4 directories, each with a copy of gp.exe and start each
>>> > of them in parallel, MPQS is much more reliable, so this suggest some race
>>> > condition.
>>>
>>>     Indeed, get_files *is* racy. I'll try to implement getpid() and some
>>>   sort of getuid() (maybe constant, maybe not). I've no native win32
>>>   compilers, so my tests will not be perfect.
>>
>> Are you sure pari_unique_dir() is racy ?
>
>     No (see below).
>
>> Maybe we should fix get_file not to be racy.
>> We should remove fix pari_unique_dir/pari_unique_filename.
>> pari_unique_filename is only used to implement pip on DOS EMX which will not
>> be missed.
>>
>> pari_unique_dir could be replaced by pari_create_unique_dir() which create the
>> directory (I think it is already the case though).
>
>       You are right. get_file and pari_unique_dir should thus not be racy...
>   However if MPQS is unreliable, it looks as if it *is* racy. Is it possible
>   that mkdir can succeed on the same dir if executed in two different
>   processes ?
>
>            Loïc
>