Boost logo

Boost :

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at