From: dizzy (dizzy_at_[hidden])
Date: 2008-07-03 09:54:23
On Tuesday 01 July 2008 15:54:42 Beman Dawes wrote:
> The remove(p) function is currently specified to return a bool with a
> value of exist(p) before the post-condition is established. The
> post-condition is !exists(p).
> The original thought in providing this was that the return value might
> be useful and would cost nothing.
> It turns out that providing this return value does have several costs:
I'm not sure why that exists check is done at all.
In POSIX at least, remove() fails with specific errno value when the to be
removed file does not exist. If the boost::filesystem::remove() semantics
want to throw in any error except the "file does not exist" one when it will
return a "false" then shouldn't it instead be checking for the errno value
Of course if the other platforms do not have something like this then just
make remove return void. Also, POSIX errno ENOENT does not exactly mean that
the file to be removed does not exist but that "the complete path given to
the file" does not exist (which also may mean that some component on the path
does not exist). From my point of view, whenever I would check for remove()
status if the file that I wanted to be removed existed or not also includes
this case so the POSIX semantics are fine with me but probably pretty
different from other platforms.
> PS: This was precipitated by ticket #1972, but doesn't affect the
> resolution of the remove() issue it raises. That will be fixed for
> 1.36.0 regardless.
Goodie, someone is solving #1972, thank you :)
-- Mihai RUSU Email: dizzy_at_[hidden] "Linux is obsolete" -- AST