[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with svn workdir over samba

From: Alan Wood <alan.wood_at_clear.net.nz>
Date: Tue, 18 Nov 2008 09:45:50 +1300

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.