.svn/entries / ERROR_DIRECTORY in APR

Hello list,

last week I had a problem with a working copy on a NFS share mounted from Linux onto Windows. I tried the following:

TortoiseProc.exe /command:showcompare /unified /url1:"J:\epson_store\frame\unity\user.php" /revision1:BASE /url2:"J:\epson_store\frame\unity\user.php" /revision2:WC

An error message popped up saying "Can't open file: J:/epson_store/frame/unity/user.php/.svn/entries". Obviously something with the path goes haywire there.

The same software with the same working copy but mounted over Samba worked fine. Everything else like committing and creating and moving files in the working copy over NFS worked fine.

I began to dig in the TortoiseSVN code but soon was directed to the SVN code itself and found the following:

A couple of functions down svn_client_diff4() is called which calls do_open() which calls svn_wc_check_wc(). At this point the path is still intact (J:/epson_store/frame/unity/user.php). Inside svn_wc_check_wc() the path of the entries file is determined by invoking svn_wc__adm_child(). This function just appends /.svn/entries to the path, without checking if the path is a directory or a file. The new path is then handed down to svn_io_read_version_file() and then to svn_io_file_open().

This is done exactly the same way in both cases (with Samba and NFS), in both cases the /.svn/entries part is appended incorrectly and in both cases svn_io_file_open() fails.

The only difference is that with Samba the windows error code is ERROR_PATH_NOT_FOUND (code 3) which APR maps to APR_ENOENT and is caught within svn_io_read_version_file(). With the NFS share however the windows error code is ERROR_DIRECTORY (code 267) which is not mapped by APR and thus not caught in svn_io_read_version_file().

Now, one could blame APR for not mapping ERROR_DIRECTORY to some platform independent APR error constant like APR_ENOTDIR, but I wonder why Subversion tries to read a path that it knows cannot exist in the first place.

Does anyone else think this may be a fixable problem within Subversion? If so, I would be happy to provide a patch, if I get some pointers as to where this (logically) goes wrong. Does svn_wc__adm_child() do a bad job of appending the path or is svn_wc_check_wc() not supposed to be called for a file instead of a directory? Or is it something that happens earlier?

Wolfgang

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2400286
Received on 2009-09-25 17:24:32 CEST