From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-31 11:17:36
Beman Dawes wrote:
> Well, you are certainly right that there are some issues that need to
> be addressed.
>
> Because is_accessible() is an attempt to deal with certain problems of
> exists(), let's go back to the original problem with exists(). Some
> errors clearly indicate the path is not present, so exists() needs to
> return false. On POSIX, those would be:
>
> [ENOENT] A component of path does not name an existing file or
> path is an empty string.
>
> [ENOTDIR] A component of the path prefix is not a directory.
>
> One POSIX error would indicate the path does exist:
>
> [EOVERFLOW] The file size in bytes or the number of blocks
> allocated to the file or the file serial number cannot be
> represented correctly in the structure pointed to by buf.
>
> But with the following errors I can't see any way to know if the path
> actually exists or not:
>
> [EACCES] Search permission is denied for a component of the path
> prefix.
> [EIO] An error occurred while reading from the file system.
>
> [ELOOP] A loop exists in symbolic links encountered during
> resolution of the path argument.
>
> [ENAMETOOLONG] The length of the path argument exceeds {PATH_MAX} or
> a pathname component is longer than {NAME_MAX}.
>
> If you agree with that analysis, then it looks like exists() should be
> changed to throw on those last four errors.
Before I agree with your analysis, I need to know what is the definition of
"exists" with respect to the observable behavior of the filesystem:: and
std:: functions that can operate on the argument.
This is not a theoretical issue. The meaning of exists( p ) is only relevant
in this context. As a user of the library, I need to know what do 'true' and
'false' mean with respect to the program logic, which consists of calls to
the filesystem:: and std:: functions. Otherwise, the return value of
exists( p ) won't be of any use (except that it can be printed to the
screen.)