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

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-02-04 07:37:23

On February 4, 2015 6:35:33 AM EST, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 4 Feb 2015 at 16:16, Gavin Lambert wrote:
> 
> > >> 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.

Yes, I was suggesting that.

> I had 
> thought you were recommending an ACL lookup for path viability.

I was thinking that would be useful while we were at it, but I recognize that's easily overreaching.

> No I meant that temp_directory_path() basically needs to iterate 
> those options I listed. If the given environment variable does not 
> expand to a valid path (note no FS operations needed here), we move 
> to the next option. We don't check for feasibility.

How would you judge that the expansion is a valid path? A regex or something else?

> For the function which creates temp files for you, it may be useful 
> to know what I'll be doing there. AFIO won't provide any facility for 
> knowing about paths of temp files until after you have created one. 
> Instead you get a dispatcher implementation which creates either 
> anonymous temp files or named temp files at some one of many unknown 
> locations until after file creation (the unknown locations which can 
> be chosen from is user suppliable, so I guess if you supply a single 
> option you get some control), plus you can request "fast moveability" 
> to another given path i.e. that the temp file location be chosen to 
> be on the same volume as the path supplied where possible, thus 
> ensuring that mv works quickly. I just added the support code for 
> that via the new statfs() call in AFIO v1.3 which might ship this 
> week or next week.

Sometimes the user needs full control over the location of temp files so they can be manually deleted when left by applications. For those that are unlinked after opening (there's a flag for that on Windows I don't recall), that's not an issue, of course. However, the code getting the temp path knows which will be done, so must be given control.

___
Rob

(Sent from my portable computation engine)