You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Dwire <sd...@pcsigroup.com> on 2003/08/22 03:03:12 UTC
RE: WC locked. Can't cleanup: ... (with original error message and log files)
-----Original Message-----
From: Philip Martin [mailto:philip@codematters.co.uk]
Sent: Thursday, August 21, 2003 8:16 PM
To: Steve Dwire
Cc: users@subversion.tigris.org
Subject: Re: WC locked. Can't cleanup: .svn/tmp/text-base is empty
> "Steve Dwire" <sd...@pcsigroup.com> writes:
>
>> Everything's going swimmingly until the update hits a snag with a io
>> error.
>
> You haven't given us this error message, it's important as it's the
> one that triggered the problem. Which version of the Subversion
> client are you using?
I'm using 0.26.0. It's the one with the Windows.exe installer. I
started over checking out to another directory to see if I could
reproduce the problem. Here's the error message:
svn_io_file_rename: can't move 'C:/SVNTest/Dest/DocStore/Data
Documents/Physicians/.svn/tmp/entries' to 'C:/SVNTest/Dest/DocStore/Data
Documents/Physicians/.svn/entries'
And here's the log file immediately after:
------------------------
<mv
dest=".svn/props/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-work"
name=".svn/tmp/props/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-work"/>
<readonly
name=".svn/props/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-work"/>
<mv
dest=".svn/prop-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"
name=".svn/tmp/prop-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"/
>
<readonly
name=".svn/prop-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"/>
<modify-entry
committed-rev="1"
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"/>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
committed-date="2003-08-21T04:30:53.952125Z"/>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
committed-date="2003-08-21T04:30:53.952125Z"/>
<modify-entry
committed-rev="1"
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"/>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
uuid="8ae5b214-e036-ab4c-80bd-f902e0739445"/>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
kind="file"
deleted="false"
revision="1"/>
<cp-and-translate
dest="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
name=".svn/tmp/text-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"/
>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
text-time="working"/>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
prop-time="working"/>
<mv
dest=".svn/text-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"
name=".svn/tmp/text-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"/
>
<readonly
name=".svn/text-base/E1B7083C8F074A84B3D99F8EE015FFF8.xml.svn-base"/>
<modify-entry
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
checksum="4f1b19e44f068b193e70e7d821580d35"/>
<modify-wcprop
name="E1B7083C8F074A84B3D99F8EE015FFF8.xml"
propname="svn:wc:ra_dav:version-url"
propval="/repos/!svn/ver/1/Dest/DocStore/Data%20Documents/Physicians/E1B
7083C8F074A84B3D99F8EE015FFF8.xml"/>
------------------------
>> One of my directories has >3200 files in it. When I look at my
>> working copy, it has fewer than 2200. No problem, I say to myself.
>> I'll just hit update again and see if it gets it up to date. Of
>> course, I hit the classic "working copy is locked" issue. I remember
>> seeing that in the FAQ, so I discover the svn cleanup command.
>>
>> When I type svn cleanup C:\test, I get the following:
>>
>> C:\>svn cleanup C:\test
>> svn: Problem running log
>> svn: in directory 'C:/test/Dest/DocStore/Data Documents/Physicians'
>
> It would be interesting to see the contents of the log file, you
> should find it at .../Physicians/.svn/log
Embedded
----------------------
<mv
dest=".svn/props/713FABD831C4441CB4272DC2E292F990.xml.svn-work"
name=".svn/tmp/props/713FABD831C4441CB4272DC2E292F990.xml.svn-work"/>
<readonly
name=".svn/props/713FABD831C4441CB4272DC2E292F990.xml.svn-work"/>
<mv
dest=".svn/prop-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"
name=".svn/tmp/prop-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"/
>
<readonly
name=".svn/prop-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"/>
<modify-entry
committed-rev="1"
name="713FABD831C4441CB4272DC2E292F990.xml"/>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
committed-date="2003-08-21T04:30:53.952125Z"/>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
committed-date="2003-08-21T04:30:53.952125Z"/>
<modify-entry
committed-rev="1"
name="713FABD831C4441CB4272DC2E292F990.xml"/>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
uuid="8ae5b214-e036-ab4c-80bd-f902e0739445"/>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
kind="file"
deleted="false"
revision="1"/>
<cp-and-translate
dest="713FABD831C4441CB4272DC2E292F990.xml"
name=".svn/tmp/text-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"/
>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
text-time="working"/>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
prop-time="working"/>
<mv
dest=".svn/text-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"
name=".svn/tmp/text-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"/
>
<readonly
name=".svn/text-base/713FABD831C4441CB4272DC2E292F990.xml.svn-base"/>
<modify-entry
name="713FABD831C4441CB4272DC2E292F990.xml"
checksum="2757dd39962b01d288c9f756efcd02a2"/>
<modify-wcprop
name="713FABD831C4441CB4272DC2E292F990.xml"
propname="svn:wc:ra_dav:version-url"
propval="/repos/!svn/ver/1/Dest/DocStore/Data%20Documents/Physicians/713
FABD831C4441CB4272DC2E292F990.xml"/>
--------------------------------
>> svn: The system cannot find the file specified.
>> svn: svn_io_copy_file: error copying 'C:/test/Dest/DocStore/Data
>> Documents/Physicians/.svn/tmp/text-base/713FABD831C4441CB4272DC2E292F
>> 990
>> .xml.svn-base' to 'C:/test/Dest/DocStore/Data
>> Documents/Physicians/713FABD831C4441CB4272DC2E292F990.xml.2.tmp'
>>
>> So I decided to do some spelunking, and I find that
>> .../Physicians/.svn/tmp/text-base is empty. No wonder svn cleanup
>> couldn't find the file specified. Now I've reached the end of the
>> FAQ, so I find myself at your mercy.
>>
>> How can I recover from this?
>
>The most reliable way to recover is to use ordinary OS operations to
>delete (or move) the Physicians directory from the working copy and
>then run update. Please look for the log file *before* deleting
>Physicians.
I tried that, but the working copy was still locked, so I had to run svn
cleanup first. That finished without complaining, but then a subsequent
update gives me this:
C:\>svn update C:\test
svn: Working copy not locked
svn: directory not locked (C:/test/Dest/DocStore/Data
Documents/Physicians)
I suppose I could zap the whole C:/test and start over, but I'd rather
not do something that drastic unless it's the only choice I have left.
S_E_D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: WC locked. Can't cleanup: ... (with original error message and
log files)
Posted by Philip Martin <ph...@codematters.co.uk>.
"Steve Dwire" <sd...@pcsigroup.com> writes:
> -----Original Message-----
> From: Philip Martin [mailto:philip@codematters.co.uk]
> Sent: Thursday, August 21, 2003 8:16 PM
> To: Steve Dwire
> Cc: users@subversion.tigris.org
> Subject: Re: WC locked. Can't cleanup: .svn/tmp/text-base is empty
>
>> "Steve Dwire" <sd...@pcsigroup.com> writes:
>>
>>> Everything's going swimmingly until the update hits a snag with a io
>>> error.
>>
>> You haven't given us this error message, it's important as it's the
>> one that triggered the problem. Which version of the Subversion
>> client are you using?
>
> I'm using 0.26.0. It's the one with the Windows.exe installer. I
> started over checking out to another directory to see if I could
> reproduce the problem. Here's the error message:
>
> svn_io_file_rename: can't move 'C:/SVNTest/Dest/DocStore/Data
> Documents/Physicians/.svn/tmp/entries' to 'C:/SVNTest/Dest/DocStore/Data
> Documents/Physicians/.svn/entries'
Was there an "Access is denied" message as well? This looks like the
Subversion on Windows filesystem problem. Nobody appears able to
reproduce the problem outside Subversion, which makes it difficult to
fix. There was a patch to retry operations that fail, but that is a
bit of a hack until we are sure about the root cause of the problem.
The error message you have given refers to the entries file, the
previous cleanup error referred to missing text base. Does the
entries error above lead to the original text base error when you
cleanup?
[...]
>>> How can I recover from this?
>>
>>The most reliable way to recover is to use ordinary OS operations to
>>delete (or move) the Physicians directory from the working copy and
>>then run update. Please look for the log file *before* deleting
>>Physicians.
>
> I tried that, but the working copy was still locked, so I had to run svn
> cleanup first. That finished without complaining, but then a subsequent
> update gives me this:
>
> C:\>svn update C:\test
> svn: Working copy not locked
> svn: directory not locked (C:/test/Dest/DocStore/Data
> Documents/Physicians)
Nasty, I'll take this bit to the dev list.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: WC locked. Can't cleanup: ... (with original error message and log files)
Posted by Sindbad the Seafarer <si...@gmx.net>.
Concerning Re: WC locked. Can't cleanup: ... (
cmpilato@collab.net wrote on 21 Aug 2003, 22:26, at least in part:
> "Steve Dwire" <sd...@pcsigroup.com> writes:
>
> > svn_io_file_rename: can't move 'C:/SVNTest/Dest/DocStore/Data
> > Documents/Physicians/.svn/tmp/entries' to 'C:/SVNTest/Dest/DocStore/Data
> > Documents/Physicians/.svn/entries'
>
> Is 'C:/SVNTest/Dest/DocStore/Data Documents/Physicians/.svn/entries'
> read-only, by any chance?
I had practically the very same error yesterday after moving the
repository to another machine and one working copy as well.
Trying to update that working copy produced the same error,
cleanup did not resolve the problem. I did not bother much with
this, however, and moved the wc out of the way and simply
checked out a fresh one. A filemanager synch transferred
added/modified files to the new working copy.
Updating another working copy via http (after relocating) was ok.
The entries file in the folder mentioned in the error message was
read only, but looking at other folders I found that obviously all are
read only.
The repository was moved to the other machine, but to the same
place there (d:\SVNRepos), the working copy just got the parent
folder renamed (d:\internet instead of d:\internet1 on the former
machine). It accessed the repository by file:///d:/SVNRepos, so
there was no change and no relocate needed.
Jan Hendrik
---------------------------------------
Freedom quote:
The only justifiable purpose of political institutions
is to assure the unhindered development of the individual.
-- Albert Einstein
---------------------------------------
Mailed with Pegasus Mail 3.12c (32bit).
Never heard of it?
Easy to use, full featured - and freely available.
And *no* automatic virus activation and spreading.
Take a look at http://www.pmail.com
Give it a try - and you'll never miss anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Index: subversion/libsvn_wc/adm_crawler.c
> ===================================================================
> --- subversion/libsvn_wc/adm_crawler.c (revision 6827)
> +++ subversion/libsvn_wc/adm_crawler.c (working copy)
> @@ -306,10 +306,11 @@
> recreate it locally, so report as missing and move
> along. Again, don't bother if we're reporting
> everything, because the dir is already missing on the server. */
> - if (missing && (! report_everything))
> + if (missing)
> {
> - SVN_ERR (reporter->delete_path (report_baton, this_path,
> - iterpool));
> + if (! report_everything)
> + SVN_ERR (reporter->delete_path (report_baton, this_path,
> + iterpool));
> continue;
> }
It looks perfect! Exactly what I was suggesting.
If it solves your reproduction-recipe bug and passes 'make check',
definitely commit it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> You're in a situation where wc -does- contain the entry for foo, but
> foo is missing on disk. Our 'low confidence' report logic falls down
> here. You're right, Philip... one step ahead of me. If the entry
> exists in the parent, but is missing from disk, we need to *not* tell
> the server about it in a low-confidence report.
>
> But now I worry what will happen if the server then tries to resend
> the directory, but the entry for it already exists in the
> parent... will that break?
I think it will work, after all "rm -rf ./foo/ && svn up ." works when
incomplete=true is not set.
How about this:
Index: subversion/libsvn_wc/adm_crawler.c
===================================================================
--- subversion/libsvn_wc/adm_crawler.c (revision 6827)
+++ subversion/libsvn_wc/adm_crawler.c (working copy)
@@ -306,10 +306,11 @@
recreate it locally, so report as missing and move
along. Again, don't bother if we're reporting
everything, because the dir is already missing on the server. */
- if (missing && (! report_everything))
+ if (missing)
{
- SVN_ERR (reporter->delete_path (report_baton, this_path,
- iterpool));
+ if (! report_everything)
+ SVN_ERR (reporter->delete_path (report_baton, this_path,
+ iterpool));
continue;
}
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Now run "svn co file://`pwd`/repo wc" under gdb and set a breakpoint
> on svn_wc__run_log. When the breakpoint is reached delete the file
> wc/foo/.svn/.svn/tmp/text-base/bar.svn-base and continue. This
> results in a failed checkout, with a locked working copy and a log
> file that won't run due to a missing file. It appears to be Steve's
> original problem, although quite how the file got deleted is a
> mystery.
Ok, I follow you so far.
> The way I would expect to recover is to "rm -rf wc/foo" and then
> update, but that doesn't work.
Ah, yes, sure.
> The working copy reporter doesn't appear to handle missing
> directories in an incomplete working copy. Looking at
> libsvn_wc/adm_crawler.c:report_revisions:309 I see that the path foo
> is correctly identified as missing, but because the
> report_everything flag is set the reporter->delete_path call is not
> made and an attempt is made to access the missing working copy.
The 'report_everything' flag is exactly what should be happening --
it's the "low confidence" reporting mode that an 'incomplete' flag
should trigger.
> Is this a bug in the incomplete=true handling, or this scenario just
> not supposed to happen?
Well, it sounds like you're experiencing a bug, but the part you
describe above is normal.
Here's what *should* happen:
* 'incomplete' flag on wc dir should cause adm_crawler to run with
'report_everything' flag.
* The first reporter command sent should be a set_path() call with
the 'start empty' argument set.
* wc has no other entries to list via set_path, so we call
finish_report().
* the server should now have a transaction that models the wc
correctly -- just an empty dir -- and thus know to send back the
missing directory.
Ahhhhh.... *now* I bet I can predict the bug.
You're in a situation where wc -does- contain the entry for foo, but
foo is missing on disk. Our 'low confidence' report logic falls down
here. You're right, Philip... one step ahead of me. If the entry
exists in the parent, but is missing from disk, we need to *not* tell
the server about it in a low-confidence report.
But now I worry what will happen if the server then tries to resend
the directory, but the entry for it already exists in the
parent... will that break?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is this a bug in the incomplete=true handling?
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> The way I would expect to recover is to "rm -rf wc/foo" and then
> update, but that doesn't work. The working copy reporter doesn't
> appear to handle missing directories in an incomplete working copy.
> Looking at libsvn_wc/adm_crawler.c:report_revisions:309 I see that the
> path foo is correctly identified as missing, but because the
> report_everything flag is set the reporter->delete_path call is not
> made and an attempt is made to access the missing working copy.
>
> Is this a bug in the incomplete=true handling, or this scenario just
> not supposed to happen?
I think the fact that removing-a-directory-and-updating doesn't work
the same way removing-a-file-and-updating does is a bug, though not a
horrifying one.
What happens if one tries to check out the directory in place as a
workaround? Does svn trip up when trying to add its entry in the
parent, because the entry is already there?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Is this a bug in the incomplete=true handling?
Posted by Philip Martin <ph...@codematters.co.uk>.
[From users@subversion]
"Steve Dwire" <sd...@pcsigroup.com> writes:
> -----Original Message-----
> From: Philip Martin [mailto:philip@codematters.co.uk]
> Sent: Thursday, August 21, 2003 8:16 PM
> To: Steve Dwire
> Cc: users@subversion.tigris.org
> Subject: Re: WC locked. Can't cleanup: .svn/tmp/text-base is empty
>
>> "Steve Dwire" <sd...@pcsigroup.com> writes:
>>
>>> svn: The system cannot find the file specified.
>>> svn: svn_io_copy_file: error copying 'C:/test/Dest/DocStore/Data
>>> Documents/Physicians/.svn/tmp/text-base/713FABD831C4441CB4272DC2E292F
>>> 990
>>> .xml.svn-base' to 'C:/test/Dest/DocStore/Data
>>> Documents/Physicians/713FABD831C4441CB4272DC2E292F990.xml.2.tmp'
>>>
>>> So I decided to do some spelunking, and I find that
>>> .../Physicians/.svn/tmp/text-base is empty. No wonder svn cleanup
>>> couldn't find the file specified. Now I've reached the end of the
>>> FAQ, so I find myself at your mercy.
>>>
>>> How can I recover from this?
>>
>>The most reliable way to recover is to use ordinary OS operations to
>>delete (or move) the Physicians directory from the working copy and
>>then run update. Please look for the log file *before* deleting
>>Physicians.
>
> I tried that, but the working copy was still locked, so I had to run svn
> cleanup first. That finished without complaining, but then a subsequent
> update gives me this:
>
> C:\>svn update C:\test
> svn: Working copy not locked
> svn: directory not locked (C:/test/Dest/DocStore/Data
> Documents/Physicians)
I can reproduce Steve's error using gdb as follows: start with a small
repository
svnadmin create repo
svn mkdir file://`pwd`/repo/foo
svn import svn-config file://`pwd`/repo/foo/bar
Now run "svn co file://`pwd`/repo wc" under gdb and set a breakpoint
on svn_wc__run_log. When the breakpoint is reached delete the file
wc/foo/.svn/.svn/tmp/text-base/bar.svn-base and continue. This
results in a failed checkout, with a locked working copy and a log
file that won't run due to a missing file. It appears to be Steve's
original problem, although quite how the file got deleted is a
mystery.
The way I would expect to recover is to "rm -rf wc/foo" and then
update, but that doesn't work. The working copy reporter doesn't
appear to handle missing directories in an incomplete working copy.
Looking at libsvn_wc/adm_crawler.c:report_revisions:309 I see that the
path foo is correctly identified as missing, but because the
report_everything flag is set the reporter->delete_path call is not
made and an attempt is made to access the missing working copy.
Is this a bug in the incomplete=true handling, or this scenario just
not supposed to happen?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: WC locked. Can't cleanup: ... (with original error message and log files)
Posted by cm...@collab.net.
"Steve Dwire" <sd...@pcsigroup.com> writes:
> svn_io_file_rename: can't move 'C:/SVNTest/Dest/DocStore/Data
> Documents/Physicians/.svn/tmp/entries' to 'C:/SVNTest/Dest/DocStore/Data
> Documents/Physicians/.svn/entries'
Is 'C:/SVNTest/Dest/DocStore/Data Documents/Physicians/.svn/entries'
read-only, by any chance?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org