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