Re: [Boost-users] boost::filesystem problems

From: Thomas Costa (oohrah_at_[hidden])
Date: 2004-08-18 10:47:51

So just add a new function (or a parameter to the old function) that 
doesn't guarantee the "succeeds or has no effect" rule. Alternately you 
could make the new behavior have the new name but it seems like you 
want the "default/standard" version to have the guarantee.

On Aug 18, 2004, at 7:31 AM, Victor A. Wagner Jr. wrote:

> Adding exception safety in the "succeeds or has no effect" to 
> copy_file certainly seem like reasonable suggestion.  It adds a small 
> complication of creating a temporary file first, but I'd say it was 
> generally worth it.  Note that _could_ change the behavior of some 
> programs that are correctly functioning now in very limited "file 
> space" and make them inoperative.
>
> At Wednesday 2004-08-18 05:19, you wrote:
>> On Tue, Aug 17, 2004 at 11:55:22PM -0700, Victor A. Wagner Jr. wrote:
>> > At Tuesday 2004-08-17 17:16, you wrote:
>> > >On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
>> > >> Hi Carlo,
>> > >>
>> > >> I just wanted to point out native_file_string is part of
>> > >> boost::filesystem::path and copy_file and rename_file (actually 
>> called
>> > >> rename) are part of boost::filesystem (operations.hpp).
>> > >
>> > >I am aware of that.  The point is that I had a need to rewrite 
>> them.
>> > >That seems to indicate that the boost implementation is flawed.
>> >
>> > perhaps you could enlighten us further?
>> > "doesn't work" is a lousy bug report
>> > "flawed" isn't a lot better.
>>
>> My problem is that Beman is not here.  It seems to make little
>> sense to try to convince people when in the end nobody is going
>> to make changes to boost when he is not here.
>>
>> But I can tell you what I improved of course.  Lets start with
>> just one case.
>>
>> boost::filesystem::copy_file starts with truncating the target
>> file - and when an error occurs, it throws - but STILL did truncate
>> the target file (assuming it already existed) (the exception at
>> the bottom of the function).
>>
>> This is not how I want exceptions to work; when an exception is
>> thrown from a function then nothing must have been changed - as
>> if the exception is thrown at the start of the function.
>>
>> My implementation of copy_file either succeeds completely or doesn't
>> do anything: it is atomic.
>>
>> I need this for robustness.  I don't write applications that '"Oops"
>> some error occured - sorry, your configuration file was erased - no
>> there is no backup, I was trying to make one namely'.  I have a gard 
>> my
>> reputation to write robust and bug free code ;).
>>
>> The other changes are mostly also related to the need for a better
>> defined post-condition in case of errors.
>>
>> --
>> Carlo Wood <carlo_at_[hidden]>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
> Victor A. Wagner Jr.      http://rudbek.com
> The five most dangerous words in the English language:
>               "There oughta be a law"
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users