Boost logo

Boost :

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. calls TMPDIR the "canonical Unix
environment variable" and refers to the following for that justification:

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.


Thanks, Jeff

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