-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Sent: Wednesday, September 07, 2005 1:21 PM To: boost@lists.boost.org Subject: Re: [boost] temp file

On Wed, 7 Sep 2005, Suman Cherukuri wrote:

<snipped>

...

Along the lines (temp file), does it make sense to add support for

creating

...

temp files in the default temp folder based on the OS (and support to override the default) with a unique name automatically generated?

--Suman

Sometimes programs need to create any file to put there same output and give this file ( for example by file name ) to another program or library. It isn't of course perfect solution, but why not if you would need it ?

This wrapper of C-function : mktemp() , frees you from duty to clean up. (removing files)

Tom

mkstemp()is recommended over mktemp to avoid file name racing. Even mkstemp is not ideal as it cannot take a const string for filename template etc. Also, we need to use something else on windows. mktemp() and mkstemp() are not natively supported on Windows but there are some 3rd party installations. If there is an equivalent in Boost which is platform independent and embedded within Filesystem namespace, it'd be very useful. --Suman

...

...

Thanks Tom _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes:

http://lists.boost.org/mailman/listinfo.cgi/boost

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

After I read the original Post I became interested in the problem as well. The realization that I came to is that there are more objects involved than just a istreams and ostreams. If you were to create an ostream that deleted the file on destruction, you'd find it to be useless since you wrote some data, but have no way whatsoever of retrieving it again. Coversely, opening a temporary istream would serve no purpose, since it would obviously contain no data. One possible solution, I felt was to have a sort of handle to the file. For example: class temp_file { public: temp_file(const path &root) { /* create file in root */ } ~temp_file() { /* delete the file */ } const path &get_path() const { return path_; } }; Then any i/ostreams that use the file hold a shared_ptr to it. The lifetime of the temp_file is arbitrary and will exist only so long as some stream is holding its pointer. So add: typedef shared_ptr<temp_file> temp_file_ptr; class temp_ofstream { public: temp_ofstream(temp_file_ptr tempFile) : tempFile_(tempFile) { } temp_ofstream(const path &root) : tempFile_(new temp_file(root) { } private temp_file_ptr tempFile_; }; Actually, the implementation I came up with used a stream_buffer derived class, but the effect is the same. To share the temp_file between ostreams and istreams, do this: temp_file_ptr file(new temp_file("")); { /* some scope */ temp_ofstream out(file); /* do stuff with out */ } { /* some other scope */ temp_ifstream in(file); /* do stuff with in */ } However, there are problems with this layout. In particular, there's race conditions with the actual filesystem object. Also, there needs to be some kind of access control to the file supplied by the temp_file object so you don't attempt to open a reader while you're writer or vice-versa. In any case, just some preliminary thoughts. Dylan Beman Dawes wrote:

"Tomek" <at@tru.pl> wrote in message news:Pine.LNX.4.58.0509071815370.26925@rex.anfa.pl...

...

Hi,

Can you add to boost::filesystem namespace class for temporary files which will remove file on object destruction ?

I prepared same sample code : http://psycho.pl/pub/src/tmpfile.cc

If you say that this is ok, I will write it using boost library and also working on win32.

I'm definitely interested, although the specification is of more interest than the actual code. I'm particularly interested in resolving any differences between POSIX and Windows, and avoiding security issues.

It is a bit surprising that this is the first request I can recall for a temporary file facility. Seems like a natural addition.

--Beman

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

It is a bit surprising that this is the first request I can recall for a temporary file facility. Seems like a natural addition.

I've been planning such a facility for iostreams, but filesystem seems

----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> Sent: Friday, September 09, 2005 10:16 AM Subject: Re: [boost] temp file [snip] like a

better home for it, especially if I don't have to code it. ;-)

temp_file would be used extensively by the iostreams (and serialization?) tests.

$0.02 Serialization will/should use "temp_file". I have been doing a bunch of related work on a persistent vector, i.e. a template that has (almost) the same i/f as std::vector but persists from one execution of an app to the next. Un-named (i.e. temporary) persistent vectors are definitely useful. Implementation of "clear" is made much simpler. Scott

Robert Ramey wrote:

And while you are thinking about this you might investigate the following:

The serialization library uses temp files to test serialization. I would prefer to use string streams to avoid using temp files at all in most cases. However, it seems that string streams on some (or all) platforms don't support things like code_cvt facets

As I've mentioned before, stringstreams *never* perform code conversion. Of the standard streams, *only* file streams use codecvts. If you want something that behaves like a stringstream but performs code conversion, you can use #include <boost/iostreams/code_converter.hpp> #include <boost/iostreams/stream.hpp> #include <libs/iostreams/example/container_device.hpp> namespace io = boost::iostreams; namespace ex = boost::iostreams::example; typedef io::code_converter< ex::container_source<std::wstring> > string_source; typedef io::code_converter< ex::container_sink<std::wstring> > string_sink; typedef io::stream<string_source> istringstream; typedef io::stream<string_sink> ostringstream;

and who know what else so I don't feel comfortable using them to test. I guess this is really a research projects re string streams.

Jonathan

Dylan Trotter wrote:

The more I think about this problem, the more I think it's about stream buffers instead of the actual streams.

Ok, that seems to make sense for your use case, but then it's completely unrelated to file management, and shouldn't even be part of boost::filesystem (but rather boost::iostream). Files and streams are completely orthogonal concepts and should be treated that way. Temporaries are no exception. Regards, Stefan

Dylan Trotter wrote:

Stefan Seefeld wrote:

...

Dylan Trotter wrote:

...

The more I think about this problem, the more I think it's about stream buffers instead of the actual streams.

Ok, that seems to make sense for your use case, but then it's completely unrelated to file management, and shouldn't even be part of boost::filesystem (but rather boost::iostream).

You're absolutely right about that. I wasn't suggesting what library it should belong to. Regardless, though, the temporary file facilities should be organized together and not strung out over a number of different libraries.

You seem to want a temporary stream (i.e. as you say, something to write into and read from). Does it really matter (for you) whether that is implemented by means of a file ? If so, what observable behavior should it have that makes it file-like ? The subject, however, suggests a temporary file, i.e. an entity in a file system. That, too, is important, as a number of people have confirmed. I don't see much relationship between them, in particular on an API level. Why would you lump them together ? Regards, Stefan

If same library uses c++ streams programer can choose between stream in memory or for example temp-file. If you need to write lot of data to stream may be it's better to have it on disk. Worst think is when you need to pass stream (or file) to other non-c++-stream lib/process. Btw, there can be also temp-directory (??). I propose to create 2 (or more?) classes : 1. Class where file will be hidden, programer will use it by file-descriptor or any other handle. On Unix file would be removed after openning. On Win32 we can use tempfile's flag to CreateFile() - file will be also invisible ?. We don't need to care about removing file on destruction. 2. Class where we can extract file name and use it. File will be removed on destruction. We need to remember about file permissins etc. 3. Any idea ? On Fri, 9 Sep 2005, Dylan Trotter wrote:

The more I think about this problem, the more I think it's about stream buffers instead of the actual streams. In particular, you have a temp_filebuf class whose lifetime determines the lifetime of the filesystem object: