Hi Konstantin
I can see from your strace that there may be an issue with a clash between
unix/windows rmdir(). Basically, unix rmdir will remove the name immediately and
window only marks the file/dir for delete when all handles are closed. The lseek(3,..)
is a bad idea on a Samba file system.
In libsvn_subr/io.c around line1843 there is code to force a non-win32 client to
rewind the directory after deleting an item when doing a recursive delete. For the
same reasons that this is taken out for windows build, it should also not be there for
samba file systems. Does anybody know why a unix system should require this
rewind?? I can't see why in the readdir_r() docs that the apr routines seem to call.
You could try removing this!
The other side of the problem is to try and stop other processes looking at these
directories at the same time. This has historically been virus checkers, but also
TourtoiseSVN if set to scan network drives.
BTW, what version of Samba are you using? There are file/directory rename issues
that also show up ( one fixed in Version 3.3.0pre2 ). Not sure if these effect unix-
unix Samba shares.
Sorry I can't test unix-unix samba at the moment, I'm just taking an interest to try and
get the windows using samba to work a bit better.
Alan Wood
On 17 Nov 2008 at 12:08, Konstantin Ryabitsev wrote:
> Hello:
>
> There appears to be a problem when an svn checkout is on a samba mount
> (server is RHEL5, client is Fedora 9). Subversion seems to try to
> delete the same file twice, and then bails out when it fails. From the
> strace:
>
> open("pylib/.svn/tmp",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFDIR|0775, st_size=0, ...}) = 0
> fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> getdents64(3, /* 5 entries */, 16384) = 144
> open("pylib/.svn/tmp/prop-base",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
> fstat64(4, {st_mode=S_IFDIR|0775, st_size=0, ...}) = 0
> getdents64(4, /* 2 entries */, 16384) = 48
> getdents64(4, /* 0 entries */, 16384) = 0
> close(4) = 0
> rmdir("pylib/.svn/tmp/prop-base") = 0
> open("pylib/.svn/tmp/props",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
> fstat64(4, {st_mode=S_IFDIR|0775, st_size=0, ...}) = 0
> getdents64(4, /* 2 entries */, 16384) = 48
> getdents64(4, /* 0 entries */, 16384) = 0
> close(4) = 0
> rmdir("pylib/.svn/tmp/props") = 0
> open("pylib/.svn/tmp/text-base",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
> fstat64(4, {st_mode=S_IFDIR|0775, st_size=0, ...}) = 0
> getdents64(4, /* 2 entries */, 16384) = 48
> getdents64(4, /* 0 entries */, 16384) = 0
> close(4) = 0
> rmdir("pylib/.svn/tmp/text-base") = 0
> getdents64(3, /* 0 entries */, 16384) = 0
> lseek(3, 0, SEEK_SET) = 0
> getdents64(3, /* 5 entries */, 16384) = 144
> open("pylib/.svn/tmp/prop-base",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
> fstat64(4, {st_mode=S_IFDIR|0775, st_size=0, ...}) = 0
> getdents64(4, 0xb957cfd0, 16384) = -1 ENOENT (No such file or directory)
> close(4) = 0
> rmdir("pylib/.svn/tmp/prop-base") = -1 ENOENT (No such file or directory)
> gettimeofday({1226688574, 416580}, NULL) = 0
> select(0, NULL, NULL, NULL, {0, 683420}) = 0 (Timeout)
> write(2, "svn: Can't remove 'pylib/.svn/tmp"..., 72) = 72
> close(3) = 0
> brk(0xb957e000) = 0xb957e000
> exit_group(1) = ?
>
> As you can see, there's two calls to rmdir("pylib/.svn/tmp/prop-base")
> -- first one succeeds, the second one fails. This is probably the same
> bug as seen in this thread:
> http://www.nabble.com/SVN-repository-possible-race-condition-td19621832.html
>
> This happens when I try to "svn switch" from trunk to a branch. The
> same operation works when on local filesystem. I can see this
> occurring on svn-1.5.2 and svn-1.5.4 (fedora 9 and fedora 10).
>
> Please advise -- I can't use subversion in our testing environment at
> the moment due to this issue. :(
>
> Cheers,
> --
> Konstantin Ryabitsev
> Montréal, Québec
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-17 21:46:09 CET