> -----Original Message-----
> From: Alan Wood [mailto:alan.wood{a}clear.net.nz]
> Sent: Monday, November 17, 2008 9:46 PM
> To: Konstantin Ryabitsev; dev_at_subversion.tigris.org
> Subject: Re: Problem with svn workdir over samba
>
> 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!
This seems to be related to issue #1896, see the comment on top of the
function:
/*
Mac OS X has a bug where if you're readding the contents of a
directory via readdir in a loop, and you remove one of the entries in
the directory and the directory has 338 or more files in it you will
skip over some of the entries in the directory. Needless to say,
this causes problems if you are using this kind of loop inside a
function that is recursively deleting a directory, because when you
get around to removing the directory it will still have something in
it.
Similar problem has been observed on FreeBSD.
See http://subversion.tigris.org/issues/show_bug.cgi?id=1896 for more
discussion and an initial solution.
To work around the problem, we do a rewinddir after we delete all files
and see if there's anything left. We repeat the steps untill there's
nothing left to delete.
This workaround causes issues on Windows where delete's are asynchronous,
however, so we never rewind if we're on Windows (the delete says it is
complete, we rewind, we see the same file and try to delete it again,
we fail.
*/
>
> 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
---------------------------------------------------------------------
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:57:47 CET