Re: [boost] [Filesystem] i18n

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-03-31 10:44:18

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