You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Toby Collett <tc...@plan9.net.nz> on 2008/09/23 06:09:24 UTC
SVN repository possible race condition
I have an SVN repository which gets into an inconsistent state and reports
errors along the following lines
Can't read directory 'db/config/.svn/tmp/text-base': Not a directory
svn cleanup will report the same errors, although the length of time between
errors and the folder it complains about change on consecutive runs.
The checkout is on a samba file share, and if I copy it to a local folder
the problem will go away.
running svn under strace show that subversion creates the folder, deletes
the folder and then proceeds to try open it.
stat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("db/schemas/.svn/tmp", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
brk(0x68f000) = 0x68f000
getdents(3, /* 2 entries */, 16384) = 48
getdents(3, /* 0 entries */, 16384) = 0
brk(0x68b000) = 0x68b000
close(3) = 0
rmdir("db/schemas/.svn/tmp") = 0
lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mkdir("db/schemas/.svn/tmp", 0777) = 0
lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
*mkdir("db/schemas/.svn/tmp/text-base", 0777) = 0*
lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mkdir("db/schemas/.svn/tmp/prop-base", 0777) = 0
lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mkdir("db/schemas/.svn/tmp/props", 0777) = 0
unlink("db/schemas/.svn/lock") = 0
lstat("db/.project", {st_mode=S_IFREG|0755, st_size=1960, ...}) = 0
open("db/.svn/prop-base/.project.svn-base", O_RDONLY) = 3
read(3, "K 14\nsvn:executable\nV 1\n*\nEND\n", 4096) = 30
close(3) = 0
open("db/.svn/prop-base/.project.svn-base", O_RDONLY) = 3
read(3, "K 14\nsvn:executable\nV 1\n*\nEND\n", 4096) = 30
close(3)
.
.
.
.
.
.
.
.
.
close(4) = 0
lstat("db/config/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("db/config/.svn/tmp/entries", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
write(3, "9\n\ndir\n3818\nhttps://svn/svn/kryt"..., 695) = 695
close(3) = 0
rename("db/config/.svn/tmp/entries", "db/config/.svn/entries") = 0
lstat("db/config/.svn/entries", {st_mode=S_IFREG|0644, st_size=695, ...}) =
0
chmod("db/config/.svn/entries", 0444) = 0
open("db/config/.svn/KILLME", O_RDONLY) = -1 ENOENT (No such file or
directory)
lstat("db/config/.svn/log", 0x7fffca82ac70) = -1 ENOENT (No such file or
directory)
lstat("db/config/.svn", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("db/config/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("db/config/.svn/tmp", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(3, /* 5 entries */, 16384) = 144
open("db/config/.svn/tmp/text-base",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(4, /* 2 entries */, 16384) = 48
getdents(4, /* 0 entries */, 16384) = 0
close(4) = 0
*rmdir("db/config/.svn/tmp/text-base") = 0*
open("db/config/.svn/tmp/props", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) =
4
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(4, /* 2 entries */, 16384) = 48
getdents(4, /* 0 entries */, 16384) = 0
close(4) = 0
rmdir("db/config/.svn/tmp/props") = 0
open("db/config/.svn/tmp/prop-base",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(4, /* 2 entries */, 16384) = 48
getdents(4, /* 0 entries */, 16384) = 0
close(4) = 0
rmdir("db/config/.svn/tmp/prop-base") = 0
getdents(3, /* 0 entries */, 16384) = 0
lseek(3, 0, SEEK_SET) = 0
getdents(3, /* 5 entries */, 16384) = 144
*open("db/config/.svn/tmp/text-base",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4*
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(4, 0x67f9b8, 16384) = -1 ENOTDIR (Not a directory)
select(0, NULL, NULL, NULL, {1, 30417}) = 0 (Timeout)
write(2, "svn: Can\'t read directory \'db/co"..., 74svn: Can't read
directory 'db/config/.svn/tmp/text-base': Not a directory
) = 74
close(4) = 0
close(3) = 0
exit_group(1) = ?
Process 24312 detached
subversion install from ubuntu hardy backports
svn --version
svn, version 1.5.1 (r32289)
compiled Sep 4 2008, 18:45:31
Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (
http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using
Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
Does anyone have any pointers as to what is wrong, is this a genuine bug? we
havent seen any of this sort of behaviour under subversion 1.4
Thanks,
Toby Collett
--
This email is intended for the addressee only and may contain privileged
and/or confidential information
Re: SVN repository possible race condition
Posted by Toby COllett <tc...@plan9.net.nz>.
A fix has been comitted to the cifs vfs git repository, and I believe it is
expected to make it into the next kernel release (2.6.29?). However this
will not help anyone running mainstream distributions much as it will take a
while to get to that kernel. I have filed a launchpad bug with a request to
have the ubuntu hardy/intrepid kernels patched..
Another note however, is that the bug I was seeing was resolved in the
client kernel module for samba (CIFS vfs module) which is not involved in
your windows clients at all.
Toby
2009/1/24 <se...@vml.com>
> Has a bug report been filed on this issue or has it been fixed?
>
> We are using Subversion's post-commit hook to auto-deploy repository
> changes out to our Windows and UNIX development servers via CIFS and NFS.
>
> The deploys to the UNIX boxes are fine but on a regular basis the working
> copies on the Windows shares blow up and it's getting worse as more
> auto-deploys are used.
>
> What I mean by the Windows working copies blowing up is our logs will show
> the following errors:
>
> svn: Can't remove file
> '/mnt/autofs/windows/10.XX.XX.XX/Inetpub/doc-root/images/.svn/lock': No such
> file or directory
> svn: Working copy '/mnt/autofs/windows/10.200.XX.XX/Inetpub/doc-root'
> locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
>
> Running 'svn cleanup' as suggested results in the following error:
>
> svn: Can't remove 'doc-root/js/.svn/tmp/prop-base': No such file or
> directory
>
>
> And running 'svn cleanup' multiple times results in the same error but
> different paths that randomly repeat:
>
> svn: Can't remove 'doc-root/js/.svn/tmp/prop-base': No such file or
> directory
> svn: Can't remove 'doc-root/controls/.svn/tmp/prop-base': No such file or
> directory
> svn: Can't remove 'doc-root/Categories/.svn/tmp/prop-base': No such file or
> directory
> svn: Can't remove 'doc-root/controls/.svn/tmp/prop-base': No such file or
> directory
>
>
> From the point we get working copy locked errors and onward, we cannot do
> anything with the working copy. We are forced to check out a new working
> copy to the Windows boxes and wait for it to happen again.
>
> In another Windows working copy, we got the following errors in our logs,
> which is probably related:
>
> svn: In directory
> '/mnt/autofs/windows/10.XX.XX.XX/Inetpub/doc-root/countries/france/resourceCenters'
> svn: Error processing command 'delete-entry' in
> '/mnt/autofs/windows/10.XX.XX.XX/Inetpub/doc-root/countries/france/resourceCenters'
> svn: Can't remove
> '/mnt/autofs/windows/10.XX.XX.XX/Inetpub/doc-root/countries/france/resourceCenters/pdf/.svn/tmp/prop-base':
> No such file or directory
> svn: Working copy '/mnt/autofs/windows/10.XX.XX.XX/Inetpub/doc-root' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
>
> We are running our Subversion server on a CentOS 5.2. The Subversion and
> apr information is:
>
> Name : subversion Relocations: (not relocatable)
> Version : 1.5.5 Vendor: Dag Apt Repository,
> http://dag.wieers.com/apt/
> Release : 0.1.el5.rf Build Date: Mon 22 Dec 2008
> 07:08:12 PM CST
> Install Date: Mon 12 Jan 2009 08:02:36 PM CST Build Host:
> lisse.hasselt.wieers.com
> Group : Development/Tools Source RPM:
> subversion-1.5.5-0.1.el5.rf.src.rpm
> Size : 17822991 License: BSD
> Signature : DSA/SHA1, Mon 22 Dec 2008 08:31:52 PM CST, Key ID
> a20e52146b8d79e6
> Packager : Dag Wieers <da...@wieers.com>
>
> Name : apr Relocations: (not relocatable)
> Version : 1.2.7 Vendor: CentOS
> Release : 11 Build Date: Wed 14 Mar 2007
> 07:00:07 AM CDT
> Install Date: Fri 23 May 2008 09:57:36 AM CDT Build Host:
> builder4.centos.org
> Group : System Environment/Libraries Source RPM:
> apr-1.2.7-11.src.rpm
> Size : 264747 License: Apache Software
> License
> Signature : DSA/SHA1, Tue 03 Apr 2007 07:19:58 PM CDT, Key ID
> a8a447dce8562897
>
--
This email is intended for the addressee only and may contain privileged
and/or confidential information
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1045322
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: SVN repository possible race condition
Posted by se...@vml.com.
Has a bug report been filed on this issue or has it been fixed?
We are using Subversion's post-commit hook to auto-deploy repository changes out to our Windows and UNIX development servers via CIFS and NFS.
The deploys to the UNIX boxes are fine but on a regular basis the working copies on the Windows shares blow up and it's getting worse as more auto-deploys are used.
What I mean by the Windows working copies blowing up is our logs will show the following errors:
svn: Can't remove file '/mnt/autofs/windows/10.XX.XX.XX/Inetpub/doc-root/images/.svn/lock': No such file or directory
svn: Working copy '/mnt/autofs/windows/10.200.XX.XX/Inetpub/doc-root' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Running 'svn cleanup' as suggested results in the following error:
svn: Can't remove 'doc-root/js/.svn/tmp/prop-base': No such file or directory
And running 'svn cleanup' multiple times results in the same error but different paths that randomly repeat:
svn: Can't remove 'doc-root/js/.svn/tmp/prop-base': No such file or directory
svn: Can't remove 'doc-root/controls/.svn/tmp/prop-base': No such file or directory
svn: Can't remove 'doc-root/Categories/.svn/tmp/prop-base': No such file or directory
svn: Can't remove 'doc-root/controls/.svn/tmp/prop-base': No such file or directory
Re: SVN repository possible race condition
Posted by Toby COllett <tc...@plan9.net.nz>.
Just a final email on the topic, this has been patched in the cifs vfs
module in the linux kernel, however it will be a while till this makes it
into mainstream distribution releases.
Toby
2009/1/7 Toby Collett
<tc...@plan9.net.nz>
>
> Hi,
> I have finally had time to look into this further, and I can confirm that
> the results are reproduceable outside subversion, I have attached a little
> test application that triggers the same behaviour just if anyone is
> interested. I am following up with the samba guys now, hopefully will have
> some success there.
>
> Just to answer the questions below:
> Both samba server and client are linux.
> Not related to server load as at nominally the same time 1.4 and 1.5
> clients are hitting the 1.4 server and only 1.5 has issues.
>
> Toby
>
> 2008/10/3 John Szakmeister <jo...@szakmeister.net>
>
>>
>> After staring at this for a while I think I know what the issue is...
>> although not technically Subversion's fault. Is your Samba share
>> hosted on Windows by chance? What I believe is happening is that
>> apr_dir_read() is returning the 'text-base' dir twice. Apparently
>> some implementations of readdir() are broken when you delete entries.
>> So on anything other than Windows, there is an attempt to rewind the
>> directory. This causes text-base to show up again, and it's a
>> directory when open() is called but has probably been removed by the
>> time getdents() is called. So we've managed to hit a race condition.
>> :-(
>>
>> Unfortunately, I'm not sure what the best solution is here. We
>> already know that the entry we were trying to remove is a directory...
>> so maybe the best answer is to check for that and skip the entry if
>> the remove fails with ENOTDIR?
>>
>> FWIW, not much of this has changed since 1.4... have you upgraded
>> whatever is hosting the share since then? Of course, if the workload
>> of the server has picked up, it could be that you were "winning" the
>> race and just not seeing the issue.
>>
>> -John
>>
>
>
>
> --
> This email is intended for the addressee only and may contain privileged
> and/or confidential information
>
--
This email is intended for the addressee only and may contain privileged
and/or confidential information
Re: SVN repository possible race condition
Posted by Toby COllett <tc...@plan9.net.nz>.
Hi,
I have finally had time to look into this further, and I can confirm that
the results are reproduceable outside subversion, I have attached a little
test application that triggers the same behaviour just if anyone is
interested. I am following up with the samba guys now, hopefully will have
some success there.
Just to answer the questions below:
Both samba server and client are linux.
Not related to server load as at nominally the same time 1.4 and 1.5 clients
are hitting the 1.4 server and only 1.5 has issues.
Toby
2008/10/3 John Szakmeister <jo...@szakmeister.net>
>
> After staring at this for a while I think I know what the issue is...
> although not technically Subversion's fault. Is your Samba share
> hosted on Windows by chance? What I believe is happening is that
> apr_dir_read() is returning the 'text-base' dir twice. Apparently
> some implementations of readdir() are broken when you delete entries.
> So on anything other than Windows, there is an attempt to rewind the
> directory. This causes text-base to show up again, and it's a
> directory when open() is called but has probably been removed by the
> time getdents() is called. So we've managed to hit a race condition.
> :-(
>
> Unfortunately, I'm not sure what the best solution is here. We
> already know that the entry we were trying to remove is a directory...
> so maybe the best answer is to check for that and skip the entry if
> the remove fails with ENOTDIR?
>
> FWIW, not much of this has changed since 1.4... have you upgraded
> whatever is hosting the share since then? Of course, if the workload
> of the server has picked up, it could be that you were "winning" the
> race and just not seeing the issue.
>
> -John
>
--
This email is intended for the addressee only and may contain privileged
and/or confidential information
Re: SVN repository possible race condition
Posted by John Szakmeister <jo...@szakmeister.net>.
On Tue, Sep 23, 2008 at 2:09 AM, Toby Collett
<tc...@plan9.net.nz> wrote:
[snip]
> stat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>
> open("db/schemas/.svn/tmp", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> brk(0x68f000) = 0x68f000
>
> getdents(3, /* 2 entries */, 16384) = 48
> getdents(3, /* 0 entries */, 16384) = 0
> brk(0x68b000) = 0x68b000
> close(3) = 0
> rmdir("db/schemas/.svn/tmp") = 0
>
> lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mkdir("db/schemas/.svn/tmp", 0777) = 0
> lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>
>
> mkdir("db/schemas/.svn/tmp/text-base", 0777) = 0
>
> lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mkdir("db/schemas/.svn/tmp/prop-base", 0777) = 0
>
> lstat("db/schemas/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mkdir("db/schemas/.svn/tmp/props", 0777) = 0
> unlink("db/schemas/.svn/lock") = 0
> lstat("db/.project", {st_mode=S_IFREG|0755, st_size=1960, ...}) = 0
>
> open("db/.svn/prop-base/.project.svn-base", O_RDONLY) = 3
> read(3, "K 14\nsvn:executable\nV 1\n*\nEND\n", 4096) = 30
> close(3) = 0
> open("db/.svn/prop-base/.project.svn-base", O_RDONLY) = 3
>
> read(3, "K 14\nsvn:executable\nV 1\n*\nEND\n", 4096) = 30
> close(3)
> .
> .
> .
> .
> .
> .
> .
> .
> .
> close(4) = 0
> lstat("db/config/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>
> open("db/config/.svn/tmp/entries", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
> write(3, "9\n\ndir\n3818\nhttps://svn/svn/kryt"..., 695) = 695
> close(3) = 0
> rename("db/config/.svn/tmp/entries", "db/config/.svn/entries") = 0
>
> lstat("db/config/.svn/entries", {st_mode=S_IFREG|0644, st_size=695, ...}) =
> 0
> chmod("db/config/.svn/entries", 0444) = 0
> open("db/config/.svn/KILLME", O_RDONLY) = -1 ENOENT (No such file or
>
> directory)
> lstat("db/config/.svn/log", 0x7fffca82ac70) = -1 ENOENT (No such file or
> directory)
> lstat("db/config/.svn", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> lstat("db/config/.svn/lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>
> open("db/config/.svn/tmp", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
> fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> getdents(3, /* 5 entries */, 16384) = 144
> open("db/config/.svn/tmp/text-base",
>
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
> fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> getdents(4, /* 2 entries */, 16384) = 48
> getdents(4, /* 0 entries */, 16384) = 0
> close(4) = 0
>
> rmdir("db/config/.svn/tmp/text-base") = 0
> open("db/config/.svn/tmp/props", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) =
> 4
> fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> getdents(4, /* 2 entries */, 16384) = 48
>
> getdents(4, /* 0 entries */, 16384) = 0
> close(4) = 0
> rmdir("db/config/.svn/tmp/props") = 0
> open("db/config/.svn/tmp/prop-base",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
>
> fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> getdents(4, /* 2 entries */, 16384) = 48
> getdents(4, /* 0 entries */, 16384) = 0
> close(4) = 0
> rmdir("db/config/.svn/tmp/prop-base") = 0
>
> getdents(3, /* 0 entries */, 16384) = 0
> lseek(3, 0, SEEK_SET) = 0
> getdents(3, /* 5 entries */, 16384) = 144
> open("db/config/.svn/tmp/text-base",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 4
>
> fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> getdents(4, 0x67f9b8, 16384) = -1 ENOTDIR (Not a directory)
> select(0, NULL, NULL, NULL, {1, 30417}) = 0 (Timeout)
> write(2, "svn: Can\'t read directory \'db/co"..., 74svn: Can't read
>
> directory 'db/config/.svn/tmp/text-base': Not a directory
> ) = 74
> close(4) = 0
> close(3) = 0
> exit_group(1) = ?
> Process 24312 detached
After staring at this for a while I think I know what the issue is...
although not technically Subversion's fault. Is your Samba share
hosted on Windows by chance? What I believe is happening is that
apr_dir_read() is returning the 'text-base' dir twice. Apparently
some implementations of readdir() are broken when you delete entries.
So on anything other than Windows, there is an attempt to rewind the
directory. This causes text-base to show up again, and it's a
directory when open() is called but has probably been removed by the
time getdents() is called. So we've managed to hit a race condition.
:-(
Unfortunately, I'm not sure what the best solution is here. We
already know that the entry we were trying to remove is a directory...
so maybe the best answer is to check for that and skip the entry if
the remove fails with ENOTDIR?
FWIW, not much of this has changed since 1.4... have you upgraded
whatever is hosting the share since then? Of course, if the workload
of the server has picked up, it could be that you were "winning" the
race and just not seeing the issue.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repository possible race condition
Posted by John Szakmeister <jo...@szakmeister.net>.
On Wed, Sep 24, 2008 at 4:48 PM, Toby Collett
<tc...@plan9.net.nz> wrote:
> The original problem was on a Linux system so any WIN32 based Macros will
> not help me unfortunately....the strace results definitely look like svn is
> doing things out of order, should I file a bug report on this issue?
It definitely sounds buggy... so, yes, you should file a bug report.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN repository possible race condition
Posted by Toby Collett <tc...@plan9.net.nz>.
The original problem was on a Linux system so any WIN32 based Macros will
not help me unfortunately....the strace results definitely look like svn is
doing things out of order, should I file a bug report on this issue?
Toby
2008/9/24 <km...@rockwellcollins.com>
>
> A potential win32 patch has previously been posted on the dev list. I
> haven't had time to test it.
>
> http://www.nabble.com/-PATCH--Working-copy-on-Samba-share-td19606426.html
>
> Kevin R.
>
> Gunnar Dalsnes <ha...@online.no> wrote on 09/23/2008 12:50:15 PM:
>
>
> > I see something (remotely) similar on Windows, where svn 1.5.X tries to
> > access something it has deleted during checkout and fails (maybe other
> > operations as well), but the special thing in my case is this happens
> > only when i monitor the file system with Microsoft Filemon:-) It works
> > fine when I don't run FileMon so I haven't thought more about it, but it
> > may be related.
> >
> > E:\Temp\ft>svn co
> > https://fishtalk.akvagroup.com:8443/svn/fishtalk/branches/2.3
> > .
> > A lib
> > A lib\SQLDMO
> > A lib\SQLDMO\Interop.SQLDMO.dll
> > A lib\SQLDMO\sqldmo.dll
> > A lib\SQLDMO\Resources
> > A lib\SQLDMO\Resources\1033
> > A lib\SQLDMO\Resources\1033\sqldmo.rll
> > A lib\TeeChart
> > A lib\TeeChart\License.txt
> > A lib\TeeChart\TeeChart.Languages.xml
> > A lib\TeeChart\changes.txt
> > A lib\TeeChart\TeeChart.dll
> > A lib\TeeChart\TeeChart.Languages.dll
> > A lib\TeeChart\TeeChart.xml
> > svn: Can't move 'lib\TeeChart\.svn\tmp\entries' to
> > 'lib\TeeChart\.svn\entries':
> > The system cannot find the file specified.
> >
> > Gunnar.
> >
> > Toby Collett wrote:
> > > I have an SVN repository which gets into an inconsistent state and
> > > reports errors along the following lines
> > > Can't read directory 'db/config/.svn/tmp/text-base': Not a directory
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
--
This email is intended for the addressee only and may contain privileged
and/or confidential information
Re: SVN repository possible race condition
Posted by km...@rockwellcollins.com.
A potential win32 patch has previously been posted on the dev list. I
haven't had time to test it.
http://www.nabble.com/-PATCH--Working-copy-on-Samba-share-td19606426.html
Kevin R.
Gunnar Dalsnes <ha...@online.no> wrote on 09/23/2008 12:50:15 PM:
> I see something (remotely) similar on Windows, where svn 1.5.X tries to
> access something it has deleted during checkout and fails (maybe other
> operations as well), but the special thing in my case is this happens
> only when i monitor the file system with Microsoft Filemon:-) It works
> fine when I don't run FileMon so I haven't thought more about it, but it
> may be related.
>
> E:\Temp\ft>svn co
> https://fishtalk.akvagroup.com:8443/svn/fishtalk/branches/2.3
> .
> A lib
> A lib\SQLDMO
> A lib\SQLDMO\Interop.SQLDMO.dll
> A lib\SQLDMO\sqldmo.dll
> A lib\SQLDMO\Resources
> A lib\SQLDMO\Resources\1033
> A lib\SQLDMO\Resources\1033\sqldmo.rll
> A lib\TeeChart
> A lib\TeeChart\License.txt
> A lib\TeeChart\TeeChart.Languages.xml
> A lib\TeeChart\changes.txt
> A lib\TeeChart\TeeChart.dll
> A lib\TeeChart\TeeChart.Languages.dll
> A lib\TeeChart\TeeChart.xml
> svn: Can't move 'lib\TeeChart\.svn\tmp\entries' to
> 'lib\TeeChart\.svn\entries':
> The system cannot find the file specified.
>
> Gunnar.
>
> Toby Collett wrote:
> > I have an SVN repository which gets into an inconsistent state and
> > reports errors along the following lines
> > Can't read directory 'db/config/.svn/tmp/text-base': Not a directory
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Re: SVN repository possible race condition
Posted by Gunnar Dalsnes <ha...@online.no>.
I see something (remotely) similar on Windows, where svn 1.5.X tries to
access something it has deleted during checkout and fails (maybe other
operations as well), but the special thing in my case is this happens
only when i monitor the file system with Microsoft Filemon:-) It works
fine when I don't run FileMon so I haven't thought more about it, but it
may be related.
E:\Temp\ft>svn co
https://fishtalk.akvagroup.com:8443/svn/fishtalk/branches/2.3
.
A lib
A lib\SQLDMO
A lib\SQLDMO\Interop.SQLDMO.dll
A lib\SQLDMO\sqldmo.dll
A lib\SQLDMO\Resources
A lib\SQLDMO\Resources\1033
A lib\SQLDMO\Resources\1033\sqldmo.rll
A lib\TeeChart
A lib\TeeChart\License.txt
A lib\TeeChart\TeeChart.Languages.xml
A lib\TeeChart\changes.txt
A lib\TeeChart\TeeChart.dll
A lib\TeeChart\TeeChart.Languages.dll
A lib\TeeChart\TeeChart.xml
svn: Can't move 'lib\TeeChart\.svn\tmp\entries' to
'lib\TeeChart\.svn\entries':
The system cannot find the file specified.
Gunnar.
Toby Collett wrote:
> I have an SVN repository which gets into an inconsistent state and
> reports errors along the following lines
> Can't read directory 'db/config/.svn/tmp/text-base': Not a directory
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org