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 10:08:56

On 4 Feb 2015 at 14:55, Domagoj Saric wrote:

> > It would have to be a very borked situation if one of those didn't
> > work.
> 
> Considering that:
> 
> 1) GetTempPath() is not deprecated (which I would take to mean that the 
> 'manufacturer of the OS' holds this function to be sufficient for 'most users')

That's a reasonable point. Apart from its hardcoded 260 char limit.

> 2) Boost.FS is already more than bloated

I certainly wouldn't call Filesystem bloated! If anything, it verges 
on being so lightweight as to not be sufficiently useful for many 
common tasks (e.g. ACL support, xattr support, file locking support). 
It also currently doesn't make strong enough guarantees about 
raciness on the filesystem in my opinion. And Windows support is 
currently poor, permissions support is faked instead of making use of 
Windows's POSIX perms emulation, and I find the ambivalent position 
on the use of extended paths unfortunate (they should be permanently 
switched on by default, though I'll accept an ability to toggle them 
off on a case by case basis).

> ...I would 'like' that the default implementation stays "as simple as possible 
> but not simpler" and add a separate function or set of functions for the various 
> special and edge cases. For example you could add a FindFile-like API that would 
> give you a token with which it would allow you to iterate possible temp. paths 
> until a working one is found [if the one returned in the last call isn't useable 
> you'd call something like get_next_temp( current_temp_path_iteration_state 
> );]...and/or you could provide the same with a container/begin-end interface...

Sounds like a recipe for racy temp file code with security holes.

No, it's better that temp file creation is written into the library 
and is done correctly without race nor security bugs. Indeed, recent 
Linuxes add special anonymous temp file semantics to the kernel, 
saves having to bother generating std::random_device temp file naming 
plus guarantees deletion on close. Very handy, and something Windows 
has had for decades. Now the only outliers are BSD and OS X.

Niall

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