Re: [boost] [filesystem] temp_dir_path()

Subject: Re: [boost] [filesystem] temp_dir_path()
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-10-10 08:50:42

Ulrich Eckhardt wrote:
> On Saturday 09 October 2010 18:36:23 Jeff Flinn wrote:
>> Posix relies on getEnv("TMPDIR"), which returns 0 if the environment
>> variable does not exist.
> 
> Question on that: Is it POSIX that actually mandates this very name anywhere? 
> If it does, I'd like to hear chapter and verse, because then, lots of software 
> doesn't conform to this and could be fixed.
> 
> In my experience, there are actually four of these TMP, TEMP, TMPDIR and 
> TEMPDIR. On my Debian system, I've redirected these to my homedir at 
> ~/tmp/{tmp,temp,tmpdir,tempdir} and looking at ~/tmp I see this:
> 
>   uli_at_fruitbox:~/tmp$ du 
>   24K     ./tmp
>   4.0K    ./tempdir
>   122M    ./tmpdir
>   24M     ./temp
> 
> plus a bunch of files under /tmp bearing my ownership, probably from programs 
> with a hard-coded path.

http://en.wikipedia.org/wiki/TMPDIR calls TMPDIR the "canonical Unix 
environment variable" and refers to the following for that justification:
 
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_03

On Mac OSX TMPDIR refers to the users temp folder.

>> Questions:
>> - should Posix return an empty path or an error when empty?
> 
> I'd say an error.

Done. See the patch attached to ticket#4742. temp_dir_path() is now 
consistent with the error handling of the rest of filesystem.

>> - should Windows provide a more 'temp-path' centric error?
> 
> I wouldn't bother. If someone needs this, they will probably file a bug 
> ticket.
> 
> 
>> - should both verify the path exists?
> 
> Yes. Question remains what fallbacks should be tried, e.g. "/tmp" on POSIX 
> systems or environment variables on non-embedded win32.

Is the above reference sufficient to only rely on TMPDIR?

>> - if the path does not exist should one be created?
> 
> No, the application should define how to handle that, not the library.

agreed.

Thanks, Jeff