RE: [boost] Re: Filesystem library: remove / etc

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-20 08:14:49

From: Dylan Nicholson [mailto:dylan_nicholson_at_[hidden]]
> 
>  --- "Stewart, Robert" <stewart_at_[hidden]> wrote: > From: Brey, 
> Edward D 
> > > > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> > > > 
> > > > I think the "basic" remove() should not throw an 
> exception for the
> > > > equivalent of ENOENT.  That is, if the postcondition is 
> > > > satisfied, then
> > > > remove() need not throw an exception, even if the file didn't 
> > > > exist when called.
> > > 
> But how are you defining the post-condition - simply that no 
> file of that name
> can be found, or that it was definitely determined that there 
> is no file in the
> relevant directory of the specified name?  The former might 

I'm defining it as the properly specified pathname does not exist.

> be true if a) the
> directory doesn't exist or can't be read or b) the device is 
> not responding.
> Surely there are some preconditions that must be satisified too?

As revealed by my post enumerating unlink()'s errors, a) and b) would
generate exceptions.

> Anyhow how hard is it to write
> 
> if (exists(filename)) remove(filename);

By the time you call remove(), exists() might return false even though it
returned true in the above.  That the file doesn't exist by the time
remove() tries to remove it is not an exceptional condition.

> Or even write a function to do this if you don't want to type 
> an extra 20
> characters...

It's not complete and the overhead of throwing, catching, decoding, and
possibly ignoring an exception isn't needed if remove() works the way I've
described it.

> I'm fully in agreement with you that 9 times out of 10 you 
> don't care whether
> remove really succeeds or not, but being forced to think 
> about the situations
> where you might care is, IMHO, a Good Thing.

I have no problems with adding a parameter to indicate that you don't care
about the condition, and I have no problems with writing "safe_remove()" in
terms of "remove()" that works the way I've described.  I question writing
"remove()" in terms of "safe_remove()."

While I understand your point about "being forced to think about situations
where you might care," I have a problem with that being 10% of the cases --
which I consider way too high -- and that ignoring the "error" is not
problematic in any cases I can imagine.  Sure, there *might* be cases in
which you'd like to know that the file to remove() didn't actually exist
when you called remove(), but not knowing doesn't cause bad things to
happen.  Indeed, you can call exists() before calling remove() if you like.
My version of remove() is perfectly safe; it doesn't (mis)lead you to do bad
things in your application: after calling it, the file is gone or an
exception is thrown.  If the file didn't exist when remove() tried to remove
it, no biggie.  If you do find one of those rare situations in which you
care whether remove() really removed the file, then you can inspect the
return value.

Rob
Susquehanna International Group, LLP
http://www.sig.com