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
>I took these errors, which may not be sufficient to cover all platforms
>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
>is likely fatal, then an exception is warranted. The only common
>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)
>in symbolic links. If the cycle is genuine, there's nothing the
>caller is likely to be able to do. If the cycle is not genuine, but
>a consequence of some unusual filesystem arrangement, few callers would
>prepared to rectify the situation. Given the rarity of this condition,
>be inclined to think that an exception is warranted.
>To make a long story short, then, I agree that we need some means by
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk