On 3.2.2015. 13:12, Niall Douglas wrote:
Corporate installs will often set USERPROFILE to a LAN samba share and TMP/TEMP to a local ramdisk or directory cleared on logout. C:\Windows will be completely read only.
There is also the use case under Terminal Services where there are two Windows directories, GetWindowsDirectory and GetSystemWindowsDirectory.
You also can't assume that any environment variables are set. If you're running as a system service you may have a blank environment and no user profile/home directory. Also, any of the Windows shell function SHxxx() will fail in this use case.
For reference, when AFIO gains temporary file dispatchers in v1.4, I was going to use the following schema as I cannot use GetTempPath (AFIO exclusively uses extended NT kernel paths and cannot use the 260 length win32 ones):
1. %TMP%
2. %TEMP%
3. %LOCALAPPDATA%\Temp
4. %USERPROFILE%\Temp
5. %HOME%\Temp
6. %ALLUSERSPROFILE%\Temp
7. %SystemRoot%\Temp
8. GetWindowsDirectory()\Temp
9. %SystemDrive%\Users\Public\Temp
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') 2) Boost.FS is already more than bloated ...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... -- Domagoj Saric Software Architect www.LittleEndian.com