--- Ben Collins-Sussman <sussman@collab.net> wrote:
> Logically, if you try to open an existing file as
> if it were a directory, you are ignoring critical
> filesystem information --
> namely, the type of the node. This is an error on
> the part of application using the filesystem.
> Yes, the path doesn't exist, but
> errors trump this fact. The application is 100%
> capable of finding out the type of the existing node
> before trying to incorrectly open
> it as a directory. Just run svn_ra_get_dir() on
> its parent.
Sure, but this implies that while using the svn_ra
library, every call to svn_ra_stat must be preceded by
one call to svn_ra_dir for each segment of the path
that is to be supplied to svn_ra_stat. So instead of
making a single call to svn_ra_stat to determine
whether a node is legit, we currently need to make n
class to svn_ra_dir + 1 to svn_ra_stat or risk having
svn_ra_stat fail because some part of the path
supplied by the client may refer to a file when they
believed it to be a folder.
>
> I suppose one could make an argument that current
> behavior is appropriate when an app calls the
> filesystem API directly
> (svn_fs.h), but a "higher level" API like svn_ra.h
> could be catching the ENOTDIR error and returning a
> NULL dirent_t. One
> could also make the argument that svn_ra_stat()
> should behave like
> a typical filesystem API itself, as it does
> already. Thoughts?
I believe its is svn_ra_stat's responsibility to
either return a dirent_t* if the node is valid or
return a NULL value. It tests each segment of the path
and then explicitly returns the error if part of the
path is a file instead of a directory. Ie it is
already doing the all work that is required of a
svn_ra_stat client to protect itself from svn_ra_stat,
ut is returning n error instead of retunring a NULL
value for the node.
William
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 13 02:55:50 2005