Re: [boost] [filesystem] scoped_file feature request?

Subject: Re: [boost] [filesystem] scoped_file feature request?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-10-12 12:53:00

On Wed, Oct 12, 2011 at 8:11 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Jorge Lodos Vigil wrote:
>> Robert Stewart wrote:
>>
>> > I created just such a temporary file class for use in our
>> > unit test library.  It uses OS-specific APIs to create a
>> > temporary file which it destroys on destruction.  Obviously,
>> > such a class must provide normal file operations to be
>> > useful, whereas scoped_file is merely concerned with removing
>> > the file upon scope exit.
>>
>> I don't believe a temporary file class _must_ provide any file
>> operation, it would be very useful by just ensuring that the
>> created temporary file is unique and exposing its name.
>
> If temporary_file creates the file but exposes no file operations, then one must call a pathname() function, close the temporary file in a way that doesn't delete it, open the pathname using another class (std::fstream, boost::filesystem::fstream, etc.), and then ensure that the other object is destroyed before the temporary_file instance removes the file (at least on Windows).  That's hardly a pleasing interface.
>
> A temporary_file class that includes file operations is, of course, beyond the current scope of Filesystem unless temporary_file were another variation of the file streams classes.
>
>> This is the problem that currently cannot be solved with
>> boost::filesystem. If temporary files are not created together
>> with the temporary path there is always a risk that the path
>> is used between the time it was found and the file was
>> created. To ensure _file_ uniqueness you must use functions
>> like tmpfile.
>
> It is enough to have a function that creates a zero-length, temporary file and returns its pathname.  That probably fits better with Filesystem's design anyway.  Such a function would have to implement a loop that calls unique_path(), tries to create a file with that pathname, and repeats some number of times until the creation succeeds.  Then, it would close the file and return the pathname.  That code is non-trivial and would be a helpful addition.

If you guys can come up with a good design for a temporary file
feature, implement and test it, and provide at lease a sketch of some
docs, I'd be happy to add it to the library. But I need to spend my
time on other aspects of the library.

One feature I've used a lot is the ability to not actually delete the
file (or directory - I often need temporary directories). When I'm
tracking down a bug it is often helpful to retain the file so it can
be inspected. That also implies knowing the path to the file.

--Beman