This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

regression in subversion with 1.7.18 (and .19)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]