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

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-02-04 07:56:10

On 4 Feb 2015 at 7:37, Rob Stewart wrote:

> > 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.

Also, Windows can only open 30k file handles per second even across 
eight CPU cores. It's an enormous performance bottleneck. And you 
can't check ACLs without opening the file.

> > 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?

Perhaps even simpler. Does the environment variable exist, and does 
it have contents.

> > 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. 

Ah, you strike exactly at a major new feature hopefully in AFIO v1.4. 
Getting temp files to behave on a Samba or NFS share which is being 
accessed concurrently by Windows and POSIX is a nest of vipers. AFIO 
will hopefully abstract away all that complexity. You get temp files 
which "just work" and you can forget about clean up.

The same code obviously enough also works on a local drive. And, 
interestingly, to make all of the above work we need a non-braindead, 
functioning and portable byte range file advisory locks abstraction 
layer, so you'll have one of those too (they are used to portably 
detect when a temp file is no longer being used, and therefore can be 
cleaned up. The special delete on close flag on Windows you mentioned 
does not work correctly on a SMB share, including on Microsoft's own 
implementation, so we can't use that. Windows also does not let you 
delete files with open handles [1]).

[1]: Actually it does if carefully asked to, AFIO uses that feature 
for its lock file implementation. Unfortunately the name of the 
deleted file continues to exist though hidden from view and any 
attempt to create a file of the same name will fail with a very 
unspecific win32 error code of ACCESS_DENIED. The workaround to match 
POSIX unlink semantics is to rename the file to a random hex name, 
_then_ to delete it.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/