You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/07/27 16:19:44 UTC
win32 svn 1.1 prompting bug (issue #1916?)
cmpilato and I are witnessing the same bug on win32.
I'm seeing it in the 1.1.0-rc1 binaries, and cmpilato is seeing it with
a build of today's /trunk.
1. Destroy the %APPDATA%\Subversion area, so there are no auth caches.
2. run 'svn ls https://svn.red-bean.com/repos/sussman'
The standard unknown client-cert prompt appears: do you want to
(R)eject the cert, accept (t)emporarily, or accept (p)ermanently?
But there's no opportunity to respond: this prompt is instantly
followed by a failed PROPFIND error, exactly as if I had typed (R)eject.
This bug isn't reproducible with a 1.0.1 win32 client.
Breser, might this bug be related to your issue #1916 prompting
changes? They were committed to trunk *just* before we made the 1.1.x
branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-07-27 at 17:32, Ben Reser wrote:
>
> Looks like it is. apr_poll() apparently doesn't work with files on
> Windows. Applied the suggested change by Brane in r10431, if someone
> can test to see if this resolves the issue it'd be nice.
Yup, I just applied r10341 to the 1.1.0-rc1 tarball, and it fixes the
problem on win32. You have my +1 for 1.1.x backport.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Ben Reser <be...@reser.org>.
On Tue, Jul 27, 2004 at 11:19:44AM -0500, Ben Collins-Sussman wrote:
> cmpilato and I are witnessing the same bug on win32.
>
> I'm seeing it in the 1.1.0-rc1 binaries, and cmpilato is seeing it with
> a build of today's /trunk.
>
> 1. Destroy the %APPDATA%\Subversion area, so there are no auth caches.
>
> 2. run 'svn ls https://svn.red-bean.com/repos/sussman'
>
> The standard unknown client-cert prompt appears: do you want to
> (R)eject the cert, accept (t)emporarily, or accept (p)ermanently?
>
> But there's no opportunity to respond: this prompt is instantly
> followed by a failed PROPFIND error, exactly as if I had typed (R)eject.
>
> This bug isn't reproducible with a 1.0.1 win32 client.
>
> Breser, might this bug be related to your issue #1916 prompting
> changes? They were committed to trunk *just* before we made the 1.1.x
> branch.
Looks like it is. apr_poll() apparently doesn't work with files on
Windows. Applied the suggested change by Brane in r10431, if someone
can test to see if this resolves the issue it'd be nice.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by François Beausoleil <fb...@ftml.net>.
Ha !
Ben Collins-Sussman wrote:
> cmpilato and I are witnessing the same bug on win32.
>
> I'm seeing it in the 1.1.0-rc1 binaries, and cmpilato is seeing it with
> a build of today's /trunk.
>
> 1. Destroy the %APPDATA%\Subversion area, so there are no auth caches.
>
> 2. run 'svn ls https://svn.red-bean.com/repos/sussman'
>
> The standard unknown client-cert prompt appears: do you want to
> (R)eject the cert, accept (t)emporarily, or accept (p)ermanently?
>
> But there's no opportunity to respond: this prompt is instantly
> followed by a failed PROPFIND error, exactly as if I had typed (R)eject.
>
> This bug isn't reproducible with a 1.0.1 win32 client.
I have the same kind of problem, but I don't even have to destroy
%APPDATA%\Subversion. See
http://www.contactor.se/~dast/svn/archive-2004-07/0891.shtml
[BUG] Commit message editor stuck in loop when no save or empty message
Bye,
François
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Ben Reser <be...@reser.org>.
On Wed, Jul 28, 2004 at 06:49:30AM +0200, Branko ??ibej wrote:
> Well, apr_poll _is_ implemented, it just happens to only work for
> sockets on Windows. I suppose hence the EBADF rather than ENOTIMPL.
I suppose that's true. But isn't EBADF a platform implementation detail
that we should be shielded from?
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Tue, Jul 27, 2004 at 11:10:07PM +0200, Branko ??ibej wrote:
>
>
>>I just looked at the apr_poll code, and unless I'm totally blind, it
>>will consistently return APR_EBADF on Windows for an APR_POLL_FILE type
>>poll. However, the wait_for_input functin in poll.c will blithely ignore
>>that error, returning APR_SUCCESS instead, because it thinks it got a
>>valid response in the pollset (i.e., it reads from the pollset what it
>>wrote into it before the call...). I think this is wrong everywhere, not
>>just on Windows.
>>
>>I think there's no other choice at this time but to have wait_for_input
>>return APR_ENOTIMPL on Windows.
>>
>>
>
>Blah. APR docs say anything not implemented must return a APR_ENOTIMPL.
>So what you're saying is the Windows support for apr_poll is incomplete
>and doesn't return that. Sounds like a bug in APR.
>
>
Well, apr_poll _is_ implemented, it just happens to only work for
sockets on Windows. I suppose hence the EBADF rather than ENOTIMPL.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Ben Reser <be...@reser.org>.
On Tue, Jul 27, 2004 at 11:10:07PM +0200, Branko ??ibej wrote:
> I just looked at the apr_poll code, and unless I'm totally blind, it
> will consistently return APR_EBADF on Windows for an APR_POLL_FILE type
> poll. However, the wait_for_input functin in poll.c will blithely ignore
> that error, returning APR_SUCCESS instead, because it thinks it got a
> valid response in the pollset (i.e., it reads from the pollset what it
> wrote into it before the call...). I think this is wrong everywhere, not
> just on Windows.
>
> I think there's no other choice at this time but to have wait_for_input
> return APR_ENOTIMPL on Windows.
Blah. APR docs say anything not implemented must return a APR_ENOTIMPL.
So what you're saying is the Windows support for apr_poll is incomplete
and doesn't return that. Sounds like a bug in APR.
Ohh well implementing the workaround you suggested.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>> cmpilato and I are witnessing the same bug on win32.
>> I'm seeing it in the 1.1.0-rc1 binaries, and cmpilato is seeing it with
>> a build of today's /trunk.
>>
>> 1. Destroy the %APPDATA%\Subversion area, so there are no auth caches.
>>
>> 2. run 'svn ls https://svn.red-bean.com/repos/sussman'
>>
>> The standard unknown client-cert prompt appears: do you want to
>> (R)eject the cert, accept (t)emporarily, or accept (p)ermanently?
>>
>> But there's no opportunity to respond: this prompt is instantly
>> followed by a failed PROPFIND error, exactly as if I had typed (R)eject.
>>
>> This bug isn't reproducible with a 1.0.1 win32 client.
>>
>> Breser, might this bug be related to your issue #1916 prompting
>> changes? They were committed to trunk *just* before we made the 1.1.x
>> branch.
>>
>>
> I just looked at the apr_poll code, and unless I'm totally blind, it
> will consistently return APR_EBADF on Windows for an APR_POLL_FILE
> type poll. However, the wait_for_input functin in poll.c
Oops, that's subversion/clients/cmdline/prompt.c
> will blithely ignore that error, returning APR_SUCCESS instead,
> because it thinks it got a valid response in the pollset (i.e., it
> reads from the pollset what it wrote into it before the call...). I
> think this is wrong everywhere, not just on Windows.
>
> I think there's no other choice at this time but to have
> wait_for_input return APR_ENOTIMPL on Windows.
>
> -- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: win32 svn 1.1 prompting bug (issue #1916?)
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>cmpilato and I are witnessing the same bug on win32.
>
>I'm seeing it in the 1.1.0-rc1 binaries, and cmpilato is seeing it with
>a build of today's /trunk.
>
>1. Destroy the %APPDATA%\Subversion area, so there are no auth caches.
>
>2. run 'svn ls https://svn.red-bean.com/repos/sussman'
>
>The standard unknown client-cert prompt appears: do you want to
>(R)eject the cert, accept (t)emporarily, or accept (p)ermanently?
>
>But there's no opportunity to respond: this prompt is instantly
>followed by a failed PROPFIND error, exactly as if I had typed (R)eject.
>
>This bug isn't reproducible with a 1.0.1 win32 client.
>
>Breser, might this bug be related to your issue #1916 prompting
>changes? They were committed to trunk *just* before we made the 1.1.x
>branch.
>
>
I just looked at the apr_poll code, and unless I'm totally blind, it
will consistently return APR_EBADF on Windows for an APR_POLL_FILE type
poll. However, the wait_for_input functin in poll.c will blithely ignore
that error, returning APR_SUCCESS instead, because it thinks it got a
valid response in the pollset (i.e., it reads from the pollset what it
wrote into it before the call...). I think this is wrong everywhere, not
just on Windows.
I think there's no other choice at this time but to have wait_for_input
return APR_ENOTIMPL on Windows.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org