On Sep 10, 2005, at 6:34 PM, williamferguson2@tigris.org wrote:
>
> What |Old value |New value
> ======================================================================
> ==========
> Status|RESOLVED |REOPENED
> ----------------------------------------------------------------------
> ----------
> Resolution|INVALID |
> ----------------------------------------------------------------------
> ----------
>
>
>
>
> ------- Additional comments from williamferguson2@tigris.org Sat
> Sep 10 16:34:28 -0700 2005 -------
> 1) I did raise this on the mailing first, as you know, since you
> eventually
> replied to it Ben.
Yes, but what you're missing here is that in this particular project,
*first* we discuss issues on the mailing list, and *then* file an
issue if there's a consensus to do so. Please don't open an issue
unless some developer asked you to, and please don't reopen issues
just because you want to discuss them. I wasn't closing the
discussion, just the issue.
In short: discuss on the list, then file issue later if everyone
agrees.
>
> 1) Not all operating systems are unix.
Do you have an example of a filesystem (on any OS) which behaves
differently?
> 2) Logically, if I supply a path that does not exist, I would
> expect it to tell
> me that it does not exist, not throw an error. While (after the
> fact) you and I
> can determine that this path is bogus, the application has no way
> of doing so at
> runtime. Doing so is the responsibility of svn_ra_stat.
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.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 11 04:33:06 2005