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-01 19:53:28

On January 31, 2015 11:29:38 AM EST, Peter Dimov <lists_at_[hidden]> wrote:
> Beman Dawes wrote:
> > temp_directory_path() on Windows is currently implemented by calling
> the 
> > Windows API GetTempPath() function.
> >
> > Ticket https://svn.boost.org/trac/boost/ticket/5300 points out that 
> > GetTempPath() does not work as expected for environmental variables
> longer 
> > than roughly 130 characters. I've added a test to Boost.Filesystem
> that 
> > verifies that boost::filesystem::temp_directory() is affected.
> >
> > The suggested fix is to use GetEnvironmentVariable to in effect
> implement 
> > GetTempPath() the way we would like it to work.
> 
> Not that the documented behavior of GetTempPath makes any sense to me
> - the 
> default temp directory is at %LOCALAPPDATA%\Temp since Win95 or so -
> but the 
> suggested fix is actually:
> 
> "A workaround is to first try to use GetEnvironmentVariable on "TMP"
> and 
> "TEMP", then fall back on GetTempPath."

You'll have to compare the strings before and after calling GetEnvironmentVariable(). It doesn't indicate whether any substitutions were made and the result could be the same length as the original.

> So, if implemented, it makes
> 
> > OTOH, excluding the Windows directory is a breaking change for
> anyone 
> > currently depending on that behavior, so I thought it best to ask
> for 
> > comments before charging ahead.
> 
> a non-issue, unless you want to avoid calling GetTempPath entirely, in
> which 
> case I would return %LOCALAPPDATA%\Temp at step 3, obtained via 
> SHGetFolderPath. 

+1
_______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

___
Rob

(Sent from my portable computation engine)