On 7/25/07, Brad Stiles <[EMAIL PROTECTED]> wrote: > I ran into a situation today concerning the command line client and windows > security. The problem is that the user (a build user performing automated > builds on a Windows 2003 VM) attempted to check out a file to a network share > and couldn't, apparently because that user doesn't have access to the share > root, even though it does have access to the directory into which the file > should be exported. > > The command I used was: > > svn export http://server/trunk/dir1/dir2/file.txt > \\server\share\dir1\dir2\dir3\file.txt --non-interactive --force > > To which svn.exe responded: > > svn: Error resolving case of '\\server\share\dir1\dir2\dir3\file.txt' > > In that tree, the user has no rights to \\server\share\, but has read/write > access to dir1 and below. If, as that user, I do 'dir \\server\share', I see > nothing, but if I do 'dir \\server\share\dir1', I see everything just fine. > > Now, in our case, that shouldn't be a problem much longer because the network > guys are in the process of changing the access rights on that directory; the > build user really should have access there. However, I don't think it's > unreasonable to assume that there might be a legitimate reason for such a > restriction. > > Is there something we did wrong here (aside from the rights issue) that would > have allowed the export to happen despite the access rights? FWIW, 'svn > checkout' resulted in the same type of error. > > When the network guy saw it, he said, "Maybe they're using the old NT4 method > of stepping through the tree, rather than going straight to the location > specified." Is there something in whatever layer svn is using for this that > accesses the tree step by step rather than as one entity? And is it worth > "fixing" if it is a problem?
Well, it's an error that finds its roots in a call to apr_filepath_merge with an argument of APR_FILEPATH_TRUENAME. Looking at that function, it calls apr_filepath_root, which tries to isolate the root in order to see whether it actually exists. That scheme breaks down when there are no read/write permissions. I have no idea whether the APR project feels this is something worth to be fixed, or even fixeable. I cc'ed their dev@ list, to make them aware if the weren't already. Hope that answers your question. bye, Erik.
