|
Boost : |
Subject: Re: [boost] [filesystem] temp_dir_path()
From: PB (newbarker_at_[hidden])
Date: 2010-10-13 17:42:39
On Wed, Oct 13, 2010 at 7:03 PM, Jeff Flinn
<TriumphSprint2000_at_[hidden]> wrote:
> John B. Turpish wrote:
>>
>> On Tue, Oct 12, 2010 at 8:49 PM, Stewart, Robert <Robert.Stewart_at_[hidden]>
>> wrote:
>>>
>>> John B. Turpish wrote:
>>>>
>>>> 'directory.in.output' provided me with nothing. So I do not
>>>> know where it got the directory for tmpnam(), but not from any
>>>> env var.
>>>
>>> According to <http://linux.die.net/man/3/tmpnam>, one should not
>>> use tmpname(3) but should instead call mkstemp(3) or tmpfile(3).
>>> The former makes a unique filename from a supplied template, so
>>> it is the caller's responsibility to select the directory. The
>>> latter creates a file which is deleted automatically when closed
>>> or when the process terminates. Neither mentions e-vars as
>>> influencing their behavior.
>>
>> What I was getting at is there's already a function in the standard C
>> library that needs to determine where to put temporary files - and in
>> my mind that would be what the temporary directory is - and its result
>> disagrees with what's being discussed here. mkstemp() doesn't have to
>> come up with directory itself - as you pointed out. tmpfile() would,
>> but printing the result of the decision not as convenient for a simple
>> test as with tmpnam(). Besides, if the use case (not positive what it
>> is, actually) was covered by tmpfile() then there would be no need for
>> the function being discussed.
>
> My primary use cases are in interacting with legacy 3rd party apps that
> read/write from/to the users temp directory with advertised file names, and
> an historical place to direct users if they want to see intermediate level
> logged data.
I get the temporary directory in Windows to create zip files in. These
get added to an email as attachments. The files need to have
well-known names formed by the application. I'm just interested in a
writable place they can be created in and then soon deleted.
Regards,
Pete
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk