Re: [boost] [filesystem] temp_directory_path() behavior on Windows

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-02-03 22:16:03

On 4/02/2015 15:04, Rob Stewart wrote:
> On February 3, 2015 7:32:37 PM EST, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>> On 3 Feb 2015 at 18:54, Rob Stewart wrote:
>>
>>> Given all of the restrictions you've enumerated, it would seem that
>> the
>>> right behavior is actually to test the existence of a possible
>> result
>>> and the caller's permission to use it before returning.
>>
>> I think it's faster to iterate all ten in that order actually. The
>> big problem with caching results is that if your temp drive is on a
>> network share, it can come and go over the lifetime of your process.
>>
>> In the end, temp files are slow on Windows, as is opening file
>> handles at all actually. That's because on NT you were never supposed
>> to use temp files when you have a NT kernel namespace to use (i.e.
>> named section objects). Unfortunately, those don't play well without
>> a bit of work with iostreams, fopen et al.
>
> I don't understand your response given what I wrote. I meant that
> those options would be tried in order to see if they resolve to a
> valid directory the caller has permissions to use and, if not, try
> the next.

Don't you have to touch the filesystem to do that?  I can imagine many 
cases where user code might want to obtain the path in contexts where 
they don't want to hit the filesystem at all (which is why the WinAPI 
call does not perform that check).

The context that wants to obtain the path is not necessarily the one 
that wants to make use of it.