You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2012/02/16 21:28:42 UTC
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Alexey,
We ask that folks send questions, concerns, and potential bug reports to
users@subversion.apache.org. (I've taken the liberty of dropping dev@ and
adding users@ to the distribution list of this response so that follow-ups
go to the right place.)
I wasn't able to easily reproduce this using Linux and a trunk version of
the codebase. (I know that's two strikes against me in terms of trying to
match your scenario. My 1.7 client build is horked at the moment, though.)
One thing that comes to mind with the situation you are seeing is the
possibility that an anti-virus software could be actively scanning the
temporary files that Subversion creates and, in doing so, blocking access to
those files from Subversion. Most modern anti-virus software packages offer
a "snooze" feature of sorts -- you might try temporarily disabling your AV
package and re-trying the checkout. If all goes well, consider adding your
checkout area to the AV package's list of excluded scan directories.
Good luck.
On 02/16/2012 12:27 PM, Alexey 0 Moudrick wrote:
> Hello, dev,
>
> I've encountered an issue with *svn copy* command.
> I report it here because I did not find a way to report in in the issue
> tracker <http://subversion.tigris.org/issues/reports.cgi>.
> It cannot copy a directory by its url to local working copy if the
> directory contains valid svn:external property.
> Instead of correct copying, it shows error like this:
>
> *svn: E720005: Can't move* 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> 'C:\t\wc\externals-container-copy': *Access is denied.*
>
> The *repro.bat* composed according to recommendations
> <http://subversion.apache.org/docs/community-guide/issues.html> is
> attached (please rename it to repro.bat).
>
> *operating systems* where I tested:
>
> *Windows 7 Professional* x86-32bit SP1 Microsoft Windows [Version 6.1.7601]
> *Windows Server 2008 R2* Standard x64-64bit SP1 Standard Microsoft Windows
> [Version 6.1.7601]
>
> *svn versions* where I tested:
>
> svn, version *1.7.2* (r1207936)
> compiled Nov 30 2011, 02:05:23
>
> svn, version *1.7.1* (r1186859)
> compiled Oct 28 2011, 13:40:58
>
> Additionaly, this makes svncopy.pl
> <http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy>
> contribution script fail on this error.
>
> Full output of repro.bat:
>
> C:\t>*repro.bat*
> Base url for repo: file:///C:/t/repos
> Making a tree for import...
> Importing it...
> Checking out working copy..
> *Creating valid svn:externals property...*
> property 'svn:externals' set on 'wc\externals-container'
> Sending wc\externals-container
>
> Committed revision 2.
> *Copying externals container from URL to WC*
> U wc\externals-container-copy
>
> Fetching external item into 'wc\externals-container-copy\ext1':
> Checked out external at revision 2.
>
>
> Fetching external item into 'wc\externals-container-copy\ext2':
> Checked out external at revision 2.
>
> Checked out revision 2.
> *svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-169DB674' to
> 'C:\t\wc\externals-container-copy': Access is denied.*
> *
> *
> --
> ----
> Best Regards
> Alexey 0 Moudrick
> =================
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> Paul Burba <pt...@gmail.com> writes:
>
>> I'm able to replicate this failure on my Windows box with my own
>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
>> expected with 1.6.17, so this appears to be a regression. Moving back
>> to the dev list.
>>
>> Investigating...
>
>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>>> 'C:\t\wc\externals-container-copy': Access is denied.
>
> I suspect this is a directory move. Perhaps the wc.db file of the
> external is still open? Can a directory be renamed on Windows when one
> of the files inside it is still open?
Stopping in svn_io_file_rename on Linux I see:
Breakpoint 2, svn_io_file_rename (
from_path=0x6b78e0 "/home/pm/sw/subversion/obj/wc/.svn/tmp/svn-E0d1tM",
to_path=0x685508 "/home/pm/sw/subversion/obj/wc/ecc", pool=0x6b5978)
and
$ ls -l /proc/10833/fd | grep subver
lrwx------ 1 pm pm 64 Feb 17 15:53 7 -> /home/pm/sw/subversion/obj/wc/.svn/wc.db
lrwx------ 1 pm pm 64 Feb 17 15:53 9 -> /home/pm/sw/subversion/obj/wc/.svn/tmp/svn-E0d1tM/e1/.svn/wc.db
so we are renaming a dir while a wc.db is open.
--
Philip
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> Paul Burba <pt...@gmail.com> writes:
>
>> I'm able to replicate this failure on my Windows box with my own
>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
>> expected with 1.6.17, so this appears to be a regression. Moving back
>> to the dev list.
>>
>> Investigating...
>
>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>>> 'C:\t\wc\externals-container-copy': Access is denied.
>
> I suspect this is a directory move. Perhaps the wc.db file of the
> external is still open? Can a directory be renamed on Windows when one
> of the files inside it is still open?
Stopping in svn_io_file_rename on Linux I see:
Breakpoint 2, svn_io_file_rename (
from_path=0x6b78e0 "/home/pm/sw/subversion/obj/wc/.svn/tmp/svn-E0d1tM",
to_path=0x685508 "/home/pm/sw/subversion/obj/wc/ecc", pool=0x6b5978)
and
$ ls -l /proc/10833/fd | grep subver
lrwx------ 1 pm pm 64 Feb 17 15:53 7 -> /home/pm/sw/subversion/obj/wc/.svn/wc.db
lrwx------ 1 pm pm 64 Feb 17 15:53 9 -> /home/pm/sw/subversion/obj/wc/.svn/tmp/svn-E0d1tM/e1/.svn/wc.db
so we are renaming a dir while a wc.db is open.
--
Philip
RE: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Paul Burba [mailto:ptburba@gmail.com]
> Sent: woensdag 22 februari 2012 17:42
> To: Nico Kadel-Garcia
> Cc: Philip Martin; C. Michael Pilato; Subversion Development; Alexey 0
> Moudrick; users@subversion.apache.org
> Subject: Re: Issue report: subversion 1.7.2 windows command line client
> cannot copy URL -> WC if URL contains externals
>
> On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia <nk...@gmail.com>
> wrote:
> > On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
> > <ph...@wandisco.com> wrote:
> >> Paul Burba <pt...@gmail.com> writes:
> >>
> >>> I'm able to replicate this failure on my Windows box with my own
> >>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
> >>> expected with 1.6.17, so this appears to be a regression. Moving back
> >>> to the dev list.
> >>>
> >>> Investigating...
> >>
> >>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> >>>> 'C:\t\wc\externals-container-copy': Access is denied.
> >>
> >> I suspect this is a directory move. Perhaps the wc.db file of the
> >> external is still open? Can a directory be renamed on Windows when one
> >> of the files inside it is still open?
> >
> > Not in my experience.
>
> I added an issue for this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4123
> and a test also:
> http://svn.apache.org/viewvc?view=revision&revision=1292090
>
> The attached patch fixes this problem on Windows. Could any wc-ng
> gurus take a look and see if this seems reasonable?
>
> [[[
> Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
>
> * subversion/include/private/svn_wc_private.h
> (svn_wc__externals_close): New declaration.
>
> * subversion/libsvn_wc/externals.c
> (svn_wc__externals_close): New definition.
>
> * subversion/libsvn_client/copy.c
> (repos_to_wc_copy_single): Use new function to close handles to
> externals' DB files before trying to rename the whole temp WC.
>
> * subversion/tests/cmdline/externals_tests.py
> (url_to_wc_copy_of_externals): Remove XFail decorator and update
> comments
> re failure status.
> ]]]
I don't think the code should be conditional for Windows. On other platforms we should also close databases that we are about to move as our references to it (via abspath) are no longer valid anyway. (And who knows what sqlite does with the path internally...)
I don't know what svn_wc__db_drop_root() does exactly, but the code should also flush some of the svn_wc__db_t internal state which maps abspaths to db handles.
It might even be easier to resolve this problem this way: just release all databases below a specific path?
Bert
>
> Even with this fix I'm still seeing odd behavior post-copy (the
> following example uses a WC-to-WC copy, but the same problem occurs
> with a URL-to-WC copy):
>
> ### We have a working copy at a uniform revision with an external:
>
> >svn up -q
>
> >svn st
> X A\C\external
>
> Performing status on external item at 'A\C\external':
>
> >svn pl -vR
> Properties on 'A\C':
> svn:externals
> ^/A/D/G external
>
> ### We copy the directory with the external definition:
>
> >svn copy A/C WC-to-WC-Copy-of-C
> A WC-to-WC-Copy-of-C
>
> ### But the external shows up as unversioned:
>
> >svn st
> X A\C\external
> A + WC-to-WC-Copy-of-C
> ? WC-to-WC-Copy-of-C\external
>
> Performing status on external item at 'WC-to-WC-Copy-of-C\external':
>
> Performing status on external item at 'A\C\external':
>
> ### Even if we commit an update the WC we see the same problem:
>
> >svn ci -m ""
> Adding WC-to-WC-Copy-of-C
>
> Committed revision 3.
>
> >svn up
> Updating '.':
>
> Fetching external item into 'WC-to-WC-Copy-of-C\external':
> External at revision 3.
>
>
> Fetching external item into 'A\C\external':
> External at revision 3.
>
> At revision 3.
>
> >svn st
> X A\C\external
> ? WC-to-WC-Copy-of-C\external
>
> Performing status on external item at 'WC-to-WC-Copy-of-C\external':
>
> Performing status on external item at 'A\C\external':
>
> >
>
> To fix this we need to remove the external via the OS then update to
> restore it (note that this problem occurs without my patch applied, so
> this is a separate issue).
>
> Paul
RE: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Paul Burba [mailto:ptburba@gmail.com]
> Sent: woensdag 22 februari 2012 17:42
> To: Nico Kadel-Garcia
> Cc: Philip Martin; C. Michael Pilato; Subversion Development; Alexey 0
> Moudrick; users@subversion.apache.org
> Subject: Re: Issue report: subversion 1.7.2 windows command line client
> cannot copy URL -> WC if URL contains externals
>
> On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia <nk...@gmail.com>
> wrote:
> > On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
> > <ph...@wandisco.com> wrote:
> >> Paul Burba <pt...@gmail.com> writes:
> >>
> >>> I'm able to replicate this failure on my Windows box with my own
> >>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
> >>> expected with 1.6.17, so this appears to be a regression. Moving back
> >>> to the dev list.
> >>>
> >>> Investigating...
> >>
> >>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> >>>> 'C:\t\wc\externals-container-copy': Access is denied.
> >>
> >> I suspect this is a directory move. Perhaps the wc.db file of the
> >> external is still open? Can a directory be renamed on Windows when one
> >> of the files inside it is still open?
> >
> > Not in my experience.
>
> I added an issue for this:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4123
> and a test also:
> http://svn.apache.org/viewvc?view=revision&revision=1292090
>
> The attached patch fixes this problem on Windows. Could any wc-ng
> gurus take a look and see if this seems reasonable?
>
> [[[
> Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
>
> * subversion/include/private/svn_wc_private.h
> (svn_wc__externals_close): New declaration.
>
> * subversion/libsvn_wc/externals.c
> (svn_wc__externals_close): New definition.
>
> * subversion/libsvn_client/copy.c
> (repos_to_wc_copy_single): Use new function to close handles to
> externals' DB files before trying to rename the whole temp WC.
>
> * subversion/tests/cmdline/externals_tests.py
> (url_to_wc_copy_of_externals): Remove XFail decorator and update
> comments
> re failure status.
> ]]]
I don't think the code should be conditional for Windows. On other platforms we should also close databases that we are about to move as our references to it (via abspath) are no longer valid anyway. (And who knows what sqlite does with the path internally...)
I don't know what svn_wc__db_drop_root() does exactly, but the code should also flush some of the svn_wc__db_t internal state which maps abspaths to db handles.
It might even be easier to resolve this problem this way: just release all databases below a specific path?
Bert
>
> Even with this fix I'm still seeing odd behavior post-copy (the
> following example uses a WC-to-WC copy, but the same problem occurs
> with a URL-to-WC copy):
>
> ### We have a working copy at a uniform revision with an external:
>
> >svn up -q
>
> >svn st
> X A\C\external
>
> Performing status on external item at 'A\C\external':
>
> >svn pl -vR
> Properties on 'A\C':
> svn:externals
> ^/A/D/G external
>
> ### We copy the directory with the external definition:
>
> >svn copy A/C WC-to-WC-Copy-of-C
> A WC-to-WC-Copy-of-C
>
> ### But the external shows up as unversioned:
>
> >svn st
> X A\C\external
> A + WC-to-WC-Copy-of-C
> ? WC-to-WC-Copy-of-C\external
>
> Performing status on external item at 'WC-to-WC-Copy-of-C\external':
>
> Performing status on external item at 'A\C\external':
>
> ### Even if we commit an update the WC we see the same problem:
>
> >svn ci -m ""
> Adding WC-to-WC-Copy-of-C
>
> Committed revision 3.
>
> >svn up
> Updating '.':
>
> Fetching external item into 'WC-to-WC-Copy-of-C\external':
> External at revision 3.
>
>
> Fetching external item into 'A\C\external':
> External at revision 3.
>
> At revision 3.
>
> >svn st
> X A\C\external
> ? WC-to-WC-Copy-of-C\external
>
> Performing status on external item at 'WC-to-WC-Copy-of-C\external':
>
> Performing status on external item at 'A\C\external':
>
> >
>
> To fix this we need to remove the external via the OS then update to
> restore it (note that this problem occurs without my patch applied, so
> this is a separate issue).
>
> Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Feb 22, 2012 at 11:42 AM, Paul Burba <pt...@gmail.com> wrote:
> Even with this fix I'm still seeing odd behavior post-copy (the
> following example uses a WC-to-WC copy, but the same problem occurs
> with a URL-to-WC copy):
.
<SNIP>
.
> To fix this we need to remove the external via the OS then update to
> restore it (note that this problem occurs without my patch applied, so
> this is a separate issue).
Added a new issue for this
http://subversion.tigris.org/issues/show_bug.cgi?id=4125
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Feb 22, 2012 at 11:42 AM, Paul Burba <pt...@gmail.com> wrote:
> Even with this fix I'm still seeing odd behavior post-copy (the
> following example uses a WC-to-WC copy, but the same problem occurs
> with a URL-to-WC copy):
.
<SNIP>
.
> To fix this we need to remove the external via the OS then update to
> restore it (note that this problem occurs without my patch applied, so
> this is a separate issue).
Added a new issue for this
http://subversion.tigris.org/issues/show_bug.cgi?id=4125
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Feb 22, 2012 at 12:36 PM, Paul Burba <pt...@gmail.com> wrote:
> On Wed, Feb 22, 2012 at 12:05 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> Index: subversion/libsvn_client/copy.c
>>> ===================================================================
>>> --- subversion/libsvn_client/copy.c (revision 1292379)
>>> +++ subversion/libsvn_client/copy.c (working copy)
>>> @@ -1519,6 +1519,17 @@
>>> ctx->notify_baton2 = old_notify_baton2;
>>>
>>> SVN_ERR(err);
>>> +
>>> +#ifdef WIN32
>>> + if (!ignore_externals)
>>> + {
>>> + /* Issue #4123: We may still hold file handles to the databases
>>> + for externals under TMP_ABSPATH. We need to release these
>>> + handles before we move TMP_ABSPATH below or Windows will
>>> + raise an ERROR_ACCESS_DENIED error. */
>>> + SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx->wc_ctx, pool));
>>> + }
>>> +#endif
>>
>> I'm not sure why this would be windows specific. Yes, Linux lets us
>> move the dir with the handle open but I think it would be an error for
>> the Subversion client to use the handle after the move.
>
> Hi Philip,
>
> OK, both you and Bert pointed this out, so it's gone.
>
>> Is this the best way to do it? It isn't what I was expecting. I was
>> expecting the checkout code to explicitly close the handles it was
>> responsible for opening. Then the copy code would not have to do
>> anything special.
>
> Are you thinking within svn_client__checkout_internal or from its
> caller, like the attached patch?
Doh, of course the attached patch *is* within on of
svn_client__checkout_internal's helpers; that's what I get for a quick
patch. This fixes the issue and passes all tests; committed it in
r1292827.
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Feb 22, 2012 at 12:36 PM, Paul Burba <pt...@gmail.com> wrote:
> On Wed, Feb 22, 2012 at 12:05 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> Index: subversion/libsvn_client/copy.c
>>> ===================================================================
>>> --- subversion/libsvn_client/copy.c (revision 1292379)
>>> +++ subversion/libsvn_client/copy.c (working copy)
>>> @@ -1519,6 +1519,17 @@
>>> ctx->notify_baton2 = old_notify_baton2;
>>>
>>> SVN_ERR(err);
>>> +
>>> +#ifdef WIN32
>>> + if (!ignore_externals)
>>> + {
>>> + /* Issue #4123: We may still hold file handles to the databases
>>> + for externals under TMP_ABSPATH. We need to release these
>>> + handles before we move TMP_ABSPATH below or Windows will
>>> + raise an ERROR_ACCESS_DENIED error. */
>>> + SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx->wc_ctx, pool));
>>> + }
>>> +#endif
>>
>> I'm not sure why this would be windows specific. Yes, Linux lets us
>> move the dir with the handle open but I think it would be an error for
>> the Subversion client to use the handle after the move.
>
> Hi Philip,
>
> OK, both you and Bert pointed this out, so it's gone.
>
>> Is this the best way to do it? It isn't what I was expecting. I was
>> expecting the checkout code to explicitly close the handles it was
>> responsible for opening. Then the copy code would not have to do
>> anything special.
>
> Are you thinking within svn_client__checkout_internal or from its
> caller, like the attached patch?
Doh, of course the attached patch *is* within on of
svn_client__checkout_internal's helpers; that's what I get for a quick
patch. This fixes the issue and passes all tests; committed it in
r1292827.
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Feb 22, 2012 at 12:05 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> Index: subversion/libsvn_client/copy.c
>> ===================================================================
>> --- subversion/libsvn_client/copy.c (revision 1292379)
>> +++ subversion/libsvn_client/copy.c (working copy)
>> @@ -1519,6 +1519,17 @@
>> ctx->notify_baton2 = old_notify_baton2;
>>
>> SVN_ERR(err);
>> +
>> +#ifdef WIN32
>> + if (!ignore_externals)
>> + {
>> + /* Issue #4123: We may still hold file handles to the databases
>> + for externals under TMP_ABSPATH. We need to release these
>> + handles before we move TMP_ABSPATH below or Windows will
>> + raise an ERROR_ACCESS_DENIED error. */
>> + SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx->wc_ctx, pool));
>> + }
>> +#endif
>
> I'm not sure why this would be windows specific. Yes, Linux lets us
> move the dir with the handle open but I think it would be an error for
> the Subversion client to use the handle after the move.
Hi Philip,
OK, both you and Bert pointed this out, so it's gone.
> Is this the best way to do it? It isn't what I was expecting. I was
> expecting the checkout code to explicitly close the handles it was
> responsible for opening. Then the copy code would not have to do
> anything special.
Are you thinking within svn_client__checkout_internal or from its
caller, like the attached patch?
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Feb 22, 2012 at 12:05 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> Index: subversion/libsvn_client/copy.c
>> ===================================================================
>> --- subversion/libsvn_client/copy.c (revision 1292379)
>> +++ subversion/libsvn_client/copy.c (working copy)
>> @@ -1519,6 +1519,17 @@
>> ctx->notify_baton2 = old_notify_baton2;
>>
>> SVN_ERR(err);
>> +
>> +#ifdef WIN32
>> + if (!ignore_externals)
>> + {
>> + /* Issue #4123: We may still hold file handles to the databases
>> + for externals under TMP_ABSPATH. We need to release these
>> + handles before we move TMP_ABSPATH below or Windows will
>> + raise an ERROR_ACCESS_DENIED error. */
>> + SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx->wc_ctx, pool));
>> + }
>> +#endif
>
> I'm not sure why this would be windows specific. Yes, Linux lets us
> move the dir with the handle open but I think it would be an error for
> the Subversion client to use the handle after the move.
Hi Philip,
OK, both you and Bert pointed this out, so it's gone.
> Is this the best way to do it? It isn't what I was expecting. I was
> expecting the checkout code to explicitly close the handles it was
> responsible for opening. Then the copy code would not have to do
> anything special.
Are you thinking within svn_client__checkout_internal or from its
caller, like the attached patch?
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> Index: subversion/libsvn_client/copy.c
> ===================================================================
> --- subversion/libsvn_client/copy.c (revision 1292379)
> +++ subversion/libsvn_client/copy.c (working copy)
> @@ -1519,6 +1519,17 @@
> ctx->notify_baton2 = old_notify_baton2;
>
> SVN_ERR(err);
> +
> +#ifdef WIN32
> + if (!ignore_externals)
> + {
> + /* Issue #4123: We may still hold file handles to the databases
> + for externals under TMP_ABSPATH. We need to release these
> + handles before we move TMP_ABSPATH below or Windows will
> + raise an ERROR_ACCESS_DENIED error. */
> + SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx->wc_ctx, pool));
> + }
> +#endif
I'm not sure why this would be windows specific. Yes, Linux lets us
move the dir with the handle open but I think it would be an error for
the Subversion client to use the handle after the move.
Is this the best way to do it? It isn't what I was expecting. I was
expecting the checkout code to explicitly close the handles it was
responsible for opening. Then the copy code would not have to do
anything special.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> Index: subversion/libsvn_client/copy.c
> ===================================================================
> --- subversion/libsvn_client/copy.c (revision 1292379)
> +++ subversion/libsvn_client/copy.c (working copy)
> @@ -1519,6 +1519,17 @@
> ctx->notify_baton2 = old_notify_baton2;
>
> SVN_ERR(err);
> +
> +#ifdef WIN32
> + if (!ignore_externals)
> + {
> + /* Issue #4123: We may still hold file handles to the databases
> + for externals under TMP_ABSPATH. We need to release these
> + handles before we move TMP_ABSPATH below or Windows will
> + raise an ERROR_ACCESS_DENIED error. */
> + SVN_ERR(svn_wc__externals_close(tmp_abspath, ctx->wc_ctx, pool));
> + }
> +#endif
I'm not sure why this would be windows specific. Yes, Linux lets us
move the dir with the handle open but I think it would be an error for
the Subversion client to use the handle after the move.
Is this the best way to do it? It isn't what I was expecting. I was
expecting the checkout code to explicitly close the handles it was
responsible for opening. Then the copy code would not have to do
anything special.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> I'm able to replicate this failure on my Windows box with my own
>>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
>>> expected with 1.6.17, so this appears to be a regression. Moving back
>>> to the dev list.
>>>
>>> Investigating...
>>
>>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>>>> 'C:\t\wc\externals-container-copy': Access is denied.
>>
>> I suspect this is a directory move. Perhaps the wc.db file of the
>> external is still open? Can a directory be renamed on Windows when one
>> of the files inside it is still open?
>
> Not in my experience.
I added an issue for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4123
and a test also: http://svn.apache.org/viewvc?view=revision&revision=1292090
The attached patch fixes this problem on Windows. Could any wc-ng
gurus take a look and see if this seems reasonable?
[[[
Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
* subversion/include/private/svn_wc_private.h
(svn_wc__externals_close): New declaration.
* subversion/libsvn_wc/externals.c
(svn_wc__externals_close): New definition.
* subversion/libsvn_client/copy.c
(repos_to_wc_copy_single): Use new function to close handles to
externals' DB files before trying to rename the whole temp WC.
* subversion/tests/cmdline/externals_tests.py
(url_to_wc_copy_of_externals): Remove XFail decorator and update comments
re failure status.
]]]
Even with this fix I'm still seeing odd behavior post-copy (the
following example uses a WC-to-WC copy, but the same problem occurs
with a URL-to-WC copy):
### We have a working copy at a uniform revision with an external:
>svn up -q
>svn st
X A\C\external
Performing status on external item at 'A\C\external':
>svn pl -vR
Properties on 'A\C':
svn:externals
^/A/D/G external
### We copy the directory with the external definition:
>svn copy A/C WC-to-WC-Copy-of-C
A WC-to-WC-Copy-of-C
### But the external shows up as unversioned:
>svn st
X A\C\external
A + WC-to-WC-Copy-of-C
? WC-to-WC-Copy-of-C\external
Performing status on external item at 'WC-to-WC-Copy-of-C\external':
Performing status on external item at 'A\C\external':
### Even if we commit an update the WC we see the same problem:
>svn ci -m ""
Adding WC-to-WC-Copy-of-C
Committed revision 3.
>svn up
Updating '.':
Fetching external item into 'WC-to-WC-Copy-of-C\external':
External at revision 3.
Fetching external item into 'A\C\external':
External at revision 3.
At revision 3.
>svn st
X A\C\external
? WC-to-WC-Copy-of-C\external
Performing status on external item at 'WC-to-WC-Copy-of-C\external':
Performing status on external item at 'A\C\external':
>
To fix this we need to remove the external via the OS then update to
restore it (note that this problem occurs without my patch applied, so
this is a separate issue).
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Feb 17, 2012 at 12:46 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> I'm able to replicate this failure on my Windows box with my own
>>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
>>> expected with 1.6.17, so this appears to be a regression. Moving back
>>> to the dev list.
>>>
>>> Investigating...
>>
>>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>>>> 'C:\t\wc\externals-container-copy': Access is denied.
>>
>> I suspect this is a directory move. Perhaps the wc.db file of the
>> external is still open? Can a directory be renamed on Windows when one
>> of the files inside it is still open?
>
> Not in my experience.
I added an issue for this:
http://subversion.tigris.org/issues/show_bug.cgi?id=4123
and a test also: http://svn.apache.org/viewvc?view=revision&revision=1292090
The attached patch fixes this problem on Windows. Could any wc-ng
gurus take a look and see if this seems reasonable?
[[[
Fix issue #4123 'URL-to-WC copy of externals fails on Windows'.
* subversion/include/private/svn_wc_private.h
(svn_wc__externals_close): New declaration.
* subversion/libsvn_wc/externals.c
(svn_wc__externals_close): New definition.
* subversion/libsvn_client/copy.c
(repos_to_wc_copy_single): Use new function to close handles to
externals' DB files before trying to rename the whole temp WC.
* subversion/tests/cmdline/externals_tests.py
(url_to_wc_copy_of_externals): Remove XFail decorator and update comments
re failure status.
]]]
Even with this fix I'm still seeing odd behavior post-copy (the
following example uses a WC-to-WC copy, but the same problem occurs
with a URL-to-WC copy):
### We have a working copy at a uniform revision with an external:
>svn up -q
>svn st
X A\C\external
Performing status on external item at 'A\C\external':
>svn pl -vR
Properties on 'A\C':
svn:externals
^/A/D/G external
### We copy the directory with the external definition:
>svn copy A/C WC-to-WC-Copy-of-C
A WC-to-WC-Copy-of-C
### But the external shows up as unversioned:
>svn st
X A\C\external
A + WC-to-WC-Copy-of-C
? WC-to-WC-Copy-of-C\external
Performing status on external item at 'WC-to-WC-Copy-of-C\external':
Performing status on external item at 'A\C\external':
### Even if we commit an update the WC we see the same problem:
>svn ci -m ""
Adding WC-to-WC-Copy-of-C
Committed revision 3.
>svn up
Updating '.':
Fetching external item into 'WC-to-WC-Copy-of-C\external':
External at revision 3.
Fetching external item into 'A\C\external':
External at revision 3.
At revision 3.
>svn st
X A\C\external
? WC-to-WC-Copy-of-C\external
Performing status on external item at 'WC-to-WC-Copy-of-C\external':
Performing status on external item at 'A\C\external':
>
To fix this we need to remove the external via the OS then update to
restore it (note that this problem occurs without my patch applied, so
this is a separate issue).
Paul
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> I'm able to replicate this failure on my Windows box with my own
>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
>> expected with 1.6.17, so this appears to be a regression. Moving back
>> to the dev list.
>>
>> Investigating...
>
>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>>> 'C:\t\wc\externals-container-copy': Access is denied.
>
> I suspect this is a directory move. Perhaps the wc.db file of the
> external is still open? Can a directory be renamed on Windows when one
> of the files inside it is still open?
Not in my experience.
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> I'm able to replicate this failure on my Windows box with my own
>> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
>> expected with 1.6.17, so this appears to be a regression. Moving back
>> to the dev list.
>>
>> Investigating...
>
>>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>>> 'C:\t\wc\externals-container-copy': Access is denied.
>
> I suspect this is a directory move. Perhaps the wc.db file of the
> external is still open? Can a directory be renamed on Windows when one
> of the files inside it is still open?
Not in my experience.
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> I'm able to replicate this failure on my Windows box with my own
> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
> expected with 1.6.17, so this appears to be a regression. Moving back
> to the dev list.
>
> Investigating...
>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>> 'C:\t\wc\externals-container-copy': Access is denied.
I suspect this is a directory move. Perhaps the wc.db file of the
external is still open? Can a directory be renamed on Windows when one
of the files inside it is still open?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> I'm able to replicate this failure on my Windows box with my own
> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
> expected with 1.6.17, so this appears to be a regression. Moving back
> to the dev list.
>
> Investigating...
>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
>> 'C:\t\wc\externals-container-copy': Access is denied.
I suspect this is a directory move. Perhaps the wc.db file of the
external is still open? Can a directory be renamed on Windows when one
of the files inside it is still open?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to be a regression. Moving back
to the dev list.
Investigating...
Paul
On Thu, Feb 16, 2012 at 3:28 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Alexey,
>
> We ask that folks send questions, concerns, and potential bug reports to
> users@subversion.apache.org. (I've taken the liberty of dropping dev@ and
> adding users@ to the distribution list of this response so that follow-ups
> go to the right place.)
>
> I wasn't able to easily reproduce this using Linux and a trunk version of
> the codebase. (I know that's two strikes against me in terms of trying to
> match your scenario. My 1.7 client build is horked at the moment, though.)
> One thing that comes to mind with the situation you are seeing is the
> possibility that an anti-virus software could be actively scanning the
> temporary files that Subversion creates and, in doing so, blocking access to
> those files from Subversion. Most modern anti-virus software packages offer
> a "snooze" feature of sorts -- you might try temporarily disabling your AV
> package and re-trying the checkout. If all goes well, consider adding your
> checkout area to the AV package's list of excluded scan directories.
>
> Good luck.
>
>
> On 02/16/2012 12:27 PM, Alexey 0 Moudrick wrote:
>
> Hello, dev,
>
> I've encountered an issue with svn copy command.
> I report it here because I did not find a way to report in in the issue
> tracker.
> It cannot copy a directory by its url to local working copy if the directory
> contains valid svn:external property.
> Instead of correct copying, it shows error like this:
>
> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> 'C:\t\wc\externals-container-copy': Access is denied.
>
> The repro.bat composed according to recommendations is attached (please
> rename it to repro.bat).
>
> operating systems where I tested:
>
> Windows 7 Professional x86-32bit SP1 Microsoft Windows [Version 6.1.7601]
> Windows Server 2008 R2 Standard x64-64bit SP1 Standard Microsoft Windows
> [Version 6.1.7601]
>
> svn versions where I tested:
>
> svn, version 1.7.2 (r1207936)
> compiled Nov 30 2011, 02:05:23
>
> svn, version 1.7.1 (r1186859)
> compiled Oct 28 2011, 13:40:58
>
> Additionaly, this makes svncopy.pl contribution script fail on this error.
>
> Full output of repro.bat:
>
> C:\t>repro.bat
> Base url for repo: file:///C:/t/repos
> Making a tree for import...
> Importing it...
> Checking out working copy..
> Creating valid svn:externals property...
> property 'svn:externals' set on 'wc\externals-container'
> Sending wc\externals-container
>
> Committed revision 2.
> Copying externals container from URL to WC
> U wc\externals-container-copy
>
> Fetching external item into 'wc\externals-container-copy\ext1':
> Checked out external at revision 2.
>
>
> Fetching external item into 'wc\externals-container-copy\ext2':
> Checked out external at revision 2.
>
> Checked out revision 2.
> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-169DB674' to
> 'C:\t\wc\externals-container-copy': Access is denied.
>
> --
> ----
> Best Regards
> Alexey 0 Moudrick
> =================
>
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Issue report: subversion 1.7.2 windows command line client cannot
copy URL -> WC if URL contains externals
Posted by Paul Burba <pt...@gmail.com>.
I'm able to replicate this failure on my Windows box with my own
builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as
expected with 1.6.17, so this appears to be a regression. Moving back
to the dev list.
Investigating...
Paul
On Thu, Feb 16, 2012 at 3:28 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Alexey,
>
> We ask that folks send questions, concerns, and potential bug reports to
> users@subversion.apache.org. (I've taken the liberty of dropping dev@ and
> adding users@ to the distribution list of this response so that follow-ups
> go to the right place.)
>
> I wasn't able to easily reproduce this using Linux and a trunk version of
> the codebase. (I know that's two strikes against me in terms of trying to
> match your scenario. My 1.7 client build is horked at the moment, though.)
> One thing that comes to mind with the situation you are seeing is the
> possibility that an anti-virus software could be actively scanning the
> temporary files that Subversion creates and, in doing so, blocking access to
> those files from Subversion. Most modern anti-virus software packages offer
> a "snooze" feature of sorts -- you might try temporarily disabling your AV
> package and re-trying the checkout. If all goes well, consider adding your
> checkout area to the AV package's list of excluded scan directories.
>
> Good luck.
>
>
> On 02/16/2012 12:27 PM, Alexey 0 Moudrick wrote:
>
> Hello, dev,
>
> I've encountered an issue with svn copy command.
> I report it here because I did not find a way to report in in the issue
> tracker.
> It cannot copy a directory by its url to local working copy if the directory
> contains valid svn:external property.
> Instead of correct copying, it shows error like this:
>
> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to
> 'C:\t\wc\externals-container-copy': Access is denied.
>
> The repro.bat composed according to recommendations is attached (please
> rename it to repro.bat).
>
> operating systems where I tested:
>
> Windows 7 Professional x86-32bit SP1 Microsoft Windows [Version 6.1.7601]
> Windows Server 2008 R2 Standard x64-64bit SP1 Standard Microsoft Windows
> [Version 6.1.7601]
>
> svn versions where I tested:
>
> svn, version 1.7.2 (r1207936)
> compiled Nov 30 2011, 02:05:23
>
> svn, version 1.7.1 (r1186859)
> compiled Oct 28 2011, 13:40:58
>
> Additionaly, this makes svncopy.pl contribution script fail on this error.
>
> Full output of repro.bat:
>
> C:\t>repro.bat
> Base url for repo: file:///C:/t/repos
> Making a tree for import...
> Importing it...
> Checking out working copy..
> Creating valid svn:externals property...
> property 'svn:externals' set on 'wc\externals-container'
> Sending wc\externals-container
>
> Committed revision 2.
> Copying externals container from URL to WC
> U wc\externals-container-copy
>
> Fetching external item into 'wc\externals-container-copy\ext1':
> Checked out external at revision 2.
>
>
> Fetching external item into 'wc\externals-container-copy\ext2':
> Checked out external at revision 2.
>
> Checked out revision 2.
> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-169DB674' to
> 'C:\t\wc\externals-container-copy': Access is denied.
>
> --
> ----
> Best Regards
> Alexey 0 Moudrick
> =================
>
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand