RE: [boost] Filesystem library: remove

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-18 11:31:15

From: Beman Dawes [mailto:bdawes_at_[hidden]]
> 
> We talked about two flavors of remove():
> 
>    remove( foobar );  // throws if foobar doesn't exist,
>                       // or otherwise can't be deleted.
> 
>    remove( foobar, nothrow); // doesn't throw ever?
> 
> The problem with the second form is that it makes it look 
> like it will 
> never throw.  If fact, if foobar exists, but can't be deleted 
> (perhaps 
> because it is read-only, in use, wrong permissions, or any 
> other reason) 
> then we still want to throw, AFAIK.
> 
> I'm thinking what we are really looking for is more like this:
> 
>    void remove_if_exists( const string & path )
>     { if ( exists( path ) remove( path ); }
> 
> Is this analysis correct?

Let me address your question by enumerating the errors that are possible
when trying to remove a file and indicate whether an exception is warranted.
I took these errors, which may not be sufficient to cover all platforms and
filesystems, from a Solaris unlink(2) manpage.

Error                                   Exception Warranted?
--------------------------------------- --------------------
Can't get to file or read only (EACCES) Yes
Mount point in use (EBUSY)              Yes
Signal occurred (EINTR)                 Yes
Too many symbolic links (ELOOP)         Probably
Name too long (ENAMETOOLONG)            Yes
No such file (ENOENT)                   No
Can't get to file's host (ENOLINK)      Yes
Bad pathname component (ENOTDIR)        Yes
Filesystem is read only (EROFS)         Yes
Dynamic library code in use (ETXTBSY)   Yes

My judgement as to whether an exception is warranted is that when the error
is likely fatal, then an exception is warranted.  The only common failure,
which indicates that there is no such file, doesn't warrant an exception.
The only question, in my mind is what to do if there is a (apparent) cycle
in symbolic links.  If the cycle is genuine, there's nothing the immediate
caller is likely to be able to do.  If the cycle is not genuine, but merely
a consequence of some unusual filesystem arrangement, few callers would be
prepared to rectify the situation.  Given the rarity of this condition, I'd
be inclined to think that an exception is warranted.

To make a long story short, then, I agree that we need some means by which
to indicate that ENOENT is acceptable.  The question is whether that
condition should ever throw an exception.  The postcondition of remove() is
that the file in question no longer exists.  If the file didn't exist on
entry, the postcondition is still satisfied.  Therefore, I think that
remove() should always return a Boolean to indicate whether the file was
actually removed from the filesystem; false would indicate that the file
didn't exist when remove() tried to remove it.

Thus,

    template <typename String>
    bool
    remove(String const & pathname_i);

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