X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:date:message-id:subject:from:to
	:content-type; q=dns; s=default; b=etrXqHpkosrQiuA6uHgBQ9RR3DOGo
	9IjvZD7lQHUE8uaEP7eYF6+iR5dYF5aWY8OgGygqDRZp/n3PQxAGXDo2coZbhycc
	lAYDFozfnFdrNVKNo7jI6W3futJBOPbAlqHdqoVjt6ecaH25T5HAxN/ZlhejerlW
	lTbQarRlFVKHTU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:date:message-id:subject:from:to
	:content-type; s=default; bh=uMfrLBzNh1lKUnq006tsb4MfnyI=; b=XII
	GE6AAWXI7sjoEYFRy1A1Npe0pmkohfbioL8I2/Aa95k9gQU+TM1nL20d54cTSN/O
	+n8sNZg5aUbIVXNRr/1ajN/OysNG0GdWGd4tZ5xC88TjuSYk1RHA2yvCcuBLP6cy
	1JL0roXLdgxpDLow6S6HCpiuBjyg9NXYnzVR8vkA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-2.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_SV autolearn=ham version=3.3.1
MIME-Version:	1.0
X-Received:	by 10.60.148.234 with SMTP id tv10mr19727642oeb.122.1369690445725; Mon, 27 May 2013 14:34:05 -0700 (PDT)
Date:	Mon, 27 May 2013 14:34:05 -0700
Message-ID:	<CACUHbYOt3CrAh6h+xkkYCXbLzvfLFtkc=juONu8j__AVn-saeA@mail.gmail.com>
Subject:	regression in subversion with 1.7.18 (and .19)
From:	David Boyce <david DOT s DOT boyce AT gmail DOT com>
To:	cygwin AT cygwin DOT com

I've encountered a regression in svn client behavior between Cygwin
1.7.17 and 1.7.18. I also tried today's snapshot which doesn't fix it,
though I suspect the problem is actually in the svn port to Cygwin,
not the DLL (by way of evidence I downgraded a 1.7.18 install to use
cygwin1.dll from 1.7.17 and it fails the same way). The problem itself
is hard to explain and maybe to reproduce but fortunately there's some
damning evidence from strace (below) which with luck will make the bug
obvious.

The symptom involves svn cached password access. Subversion can be
told to cache the user's password in
~/.subversion/auth/svn.simple/<hashed-value> and this is how we use
it. On Cygwin, we point $HOME at the UNC path to our home directories
on a filer and up through Cygwin 1.7.17 (which bundles svn 1.6.16)
this works. Starting with 1.7.18 (svn 1.7.9) it absolutely refuses to
find the cached password via this network path, even if we point to it
explicitly using svn --config-dir=$HOME/.subversion. If we copy the
same path to a local filesystem and point at it with --config-dir, it
works. A really interesting data point is that if we even make a local
*symlink" whose target is the network path and point at that with
--config-dir, it still works. As long as it's a local directory or we
can trick svn into thinking it's a local directory, it works.

Also, the failure is not observed in a fully logged-in Cygwin session.
We see it when using LSF, which is sort of analogous to ssh in the
sense of being a daemon which starts jobs based on network requests.
I'd guess it could be reproduced with ssh but it would take some setup
for me to try that here so I'm hoping the bug can be found without it.

Looking at strace logs is quite illuminating (note that I've scrubbed
these of company identification). Here are the first two lines from a
working (1.7.17) usage:

% grep 'prefix.company.com.*svn.simple' svn.17 | head -2
   48   33186 [main] svn 776 normalize_posix_path: src
//prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple
   17   33203 [main] svn 776 normalize_posix_path:
//prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple =
normalize_posix_path
(//prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple)

And from the non-working 1.7.18:

% grep 'prefix.company.com.*svn.simple' svn.18 | head -2
   22  253378 [main] svn 5848 normalize_posix_path: src
/prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple/1b794458a0e19fc8211326d47216f19b
   34  253412 [main] svn 5848 normalize_posix_path:
/prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple/1b794458a0e19fc8211326d47216f19b
= normalize_posix_path
(/prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple/1b794458a0e19fc8211326d47216f19b)

Notice two things:

(1) The double leading // has become a single /.
(2) The working version normalizes the directory whereas the broken
use includes the filename in its path (the full correct path to the
file containing the password is
"//prefix.company.com/xyz/home/builder/.subversion/auth/svn.simple/1b794458a0e19fc8211326d47216f19b").

Taken together it implies an off-by-one error causing a leading
pathname component to be dropped and a corresponding trailing
component to be added.

David Boyce

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -