[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: r877014 - on Windows, invalid path => svn_node_none [was: svn commit: r930333 - /subversion/branches/1.6.x/STATUS]

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 7 Apr 2010 10:42:54 -0400

On Wed, Apr 7, 2010 at 9:46 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Paul Burba [mailto:ptburba_at_gmail.com]
>> Sent: woensdag 7 april 2010 15:27
>> To: Bert Huijben
>> Cc: Julian Foad; rhuijben_at_apache.org; dev_at_subversion.apache.org
>> Subject: Re: r877014 - on Windows, invalid path => svn_node_none [was: svn
>> commit: r930333 - /subversion/branches/1.6.x/STATUS]
>> Bert...don't kill me, but where in either r877014 or my alternative
>> patch are we returning an error we didn't return before?
> Before r877014 we returned an error on paths as "C:\path\that\is:invalid", but we didn't return an error on an equally invalid path "//q:" (format is "//server/share" or "q:/") that happens to return ERROR_BAD_PATHNAME instead of ERROR_INVALID_NAME because it is handled in another layer of the Windows path redirector.
> So what I tried to say is that the APR_STATUS_IS_ENOENT() and APR_STATUS_IS_ENOTDIR() checks catch almost every path syntax error, but not this specific one. I fixed this by also handling this error like the other bad pathnames. An equally valid (or possibly better) route is to handle all these invalid path errors as an error.

Thanks Bert,

That makes r877014 clear (and compelling) particularly when combined
with Julian's doc patch, which I see he just committed.

Sorry for the confusion.

Received on 2010-04-07 16:43:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.