Erik Huelsmann wrote: > 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.
This presumes it's an error at all. The _TRUENAME flag tells us that we MUST use the canonical path. The *only* way to accomplish this is with read/traverse access through the file path. The arguements for this approach is that an app (such as a server) often needs to deal with the single proper name of a resource. Program Files may be Progra~1, it may also be Progra~2, or on netware, ProgramF. > 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. Of course it won't be fixed, because it is not broken. Bill
