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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk