Re: [boost] Filesystem library: remove

From: Rainer Deyke (root_at_[hidden])
Date: 2002-03-18 14:03:43

----- Original Message -----
From: "Stewart, Robert" <stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 18, 2002 9:31 AM
Subject: RE: [boost] Filesystem library: remove

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

<reorganize>

> Name too long (ENAMETOOLONG)            Yes
> No such file (ENOENT)                   No
> Bad pathname component (ENOTDIR)        Yes

These all imply that the file doesn't exist, right?  Why throw an
exception in some cases but not in others?

> Can't get to file or read only (EACCES) Yes
> Filesystem is read only (EROFS)         Yes
> Mount point in use (EBUSY)              Yes
> Dynamic library code in use (ETXTBSY)   Yes

These imply that the file exists but can't be deleted (for now):
genuine failure.

> Signal occurred (EINTR)                 Yes
> Too many symbolic links (ELOOP)         Probably
> Can't get to file's host (ENOLINK)      Yes

I'm not exactly sure what these mean, so no comment.

> My judgement as to whether an exception is warranted is that when
the error
> is likely fatal, then an exception is warranted.

Whether or not an error is fatal depends entirely on the context.
Here's a list of some possible reasons why one might want to delete a
file:

Direct user request: If the operation fails, this should be reported
to the user (along with the specific type of failure).  It is not
fatal in the larger sense.

Removal of temporary files: Failure is generally not critical; it just
leaves some garbage on the user's disk.  Should probably be
logged/reported and then ignored.

Uninstalling something from the system: Failure should be reported to
the user, who may then be given the option of correcting the error,
ignoring it, and/or aborting the entire program.

Removing a file that is used as an inter-process mutex: Failure (of
any kind) is probably fatal.

--
Rainer Deyke | root_at_[hidden] | http://rainerdeyke.com