
At 06:02 AM 3/31/2005, Peter Dimov wrote:
...
Did is_accessible get added, after all?
Yes.
That's bad. Let's remove it before it gets standardized and it's too late. :-)
?
It is a hack. Only "useful" on Windows, and only because of implementation details. It is not clear what is_accessible actually does, or why it should
be used. It is not referenced anywhere else. The implementation does not reflect the description; on Windows it maps to GetFileAttributes and returns false if that fails, but for some "inaccessible" files it is possible to obtain the attributes using FindFirstFile.
The latter is particularly relevant in directory iteration loops; every item in such an iteration is "accessible" because the act of iteration gives you the attributes on our supported platforms. Yet is_accessible returns false for some of the items.
I may be wrong, of course.
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. is_accessible() would have a role in that it would return false on those same four errors because regardless of whether or not the path exists, it clearly isn't accessible. And each of the places exists() is used in the operations docs for other functions needs to be examined to see if is_accessible() is really the requirement. On Windows the analysis is more difficult because the exact set of possible errors is not specified, and because of the FindFirstFile backdoor. Let's get a reaction to my POSIX analysis above before worrying about Windows. --Beman