RE: [boost] Filesystem library: remove / etc

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-18 16:10:52

At 11:31 AM 3/18/2002, Stewart, Robert wrote:

 >> 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.

OK.  Thanks for the extended analysis.

 >  The question is whether that
 >condition should ever throw an exception.

I've seen a lot of errors that first manifested themselves as removal of a 
file failing because the file did not exist.

The general approach I'm working on is a set of basic functions, and then 
an additional set of convenience functions.  The convenience functions 
could be implemented in terms of the basic functions, although for 
efficiency an implementation might not choose to do that.

The basic functions are indivisible, non-recursive, very specific, (and 
thus efficient), and are extremely picky about errors.

The convenience functions, besides providing recursion, regular expression 
and other filtering, and similar commonly needed features, will also treat 
errors in the context of typical use.  Thus remove() resulting in ENOENT 
wouldn't throw an exception, for example.

By the way, in working various usage examples, it has become obvious that a 
fair number of uses of directory iterators need to recurse into 
sub-directories.  Sometimes depth first, sometimes breadth first.  Whether 
that need is common enough to justify either adapter iterators, or a 
directory iterator option, I don't know yet.

--Beman