You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by jimbobmcgee <us...@jimbobmcgee.com> on 2019/11/20 15:17:50 UTC
Windows 10 November 2019 security updates affecting file:// to Win2003 shares?
HI all;
Appreciating the woefully out-of-date/unsupported nature of my setup, I thought it might be worth dropping a line to see if anyone else out there might be experiencing issues since this month's Patch Tuesday release.
Prior to the November 2019 updates, our Windows 10 users were successfully using Subversion and/or TortoiseSVN to commit to some old v1.6 repositories stored on a Windows Server 2003 R2 file share, using the file:// protocol. After the November 2019 updates, they are now all told that we "Can't write '/pathto/repo/db/txn-current' atomically: Permission denied" (paraphrased).
No changes were made to the Windows Server (i.e. this isn't a case of the permissions being changed on the server without our knowing).
Running a Procmon (SysInternals) trace during the commit process suggests that the updated Win10 clients are getting a different behaviour when the txn-HEX file is renamed to txn-current. Procmon reports that a SetRenameInformationFile operation gets a 0xC00000D5 error, where not-updated clients do not get an error.
I can't find much on the error code 0xC00000D5, except in a NTSTATUS values reference, where it suggests that the source file might already have been renamed.
We've tried here with svn.exe builds (from sliksvn.com) and TortoiseSVN builds at both v1.11.1 and v1.13.0. Commits to another Win2008R2 server are successful, as are commits from anyone who hasn't installed the November 2019 updates.
Not expecting anything to be done to support such an old setup, of course -- we have now moved all our repositories to another server -- but I thought I'd see if anyone else was experiencing the same issue? At least it might be searchable for future generations!
J.
Re: Windows 10 November 2019 security updates affecting file:// to
Win2003 shares?
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Nov 20, 2019 at 2:21 PM jimbobmcgee <users~
subversion.apache.org@jimbobmcgee.com> wrote:
> Hi Nathan;
>
> We did not go down that route -- we simply moved our repositories to a
> newer-edition Windows file server, and used a DNS alias so that the
> end-users weren't affected for too long. It is part of our ongoing server
> refresh plan to move to a svn://- or https://-based solution in the near
> future, but we needed a short-term fix
>
> The email to users@ was more a PSA than request for help, and also to see
> if my findings wre matched by anyone else.
>
> Thanks, though.
>
I see. Thank you for writing.
If you need help with moving to svn:// or https://, we're here. :-)
Nathan
Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares?
Posted by jimbobmcgee <us...@jimbobmcgee.com>.
Hi Nathan;
We did not go down that route -- we simply moved our repositories to a newer-edition Windows file server, and used a DNS alias so that the end-users weren't affected for too long. It is part of our ongoing server refresh plan to move to a svn://- or https://-based solution in the near future, but we needed a short-term fix
The email to users@ was more a PSA than request for help, and also to see if my findings wre matched by anyone else.
Thanks, though.
J.
----- Original message -----
From: Nathan Hartman <ha...@gmail.com>
To: jimbobmcgee <us...@jimbobmcgee.com>
Cc: users@subversion.apache.org
Subject: Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares?
Date: Wednesday, 20 November 2019 17:57
On Wed, Nov 20, 2019 at 10:59 AM jimbobmcgee <us...@jimbobmcgee.com> wrote:
> HI all;
>
> Appreciating the woefully out-of-date/unsupported nature of my setup, I thought it might be worth dropping a line to see if anyone else out there might be experiencing issues since this month's Patch Tuesday release.
>
> Prior to the November 2019 updates, our Windows 10 users were successfully using Subversion and/or TortoiseSVN to commit to some old v1.6 repositories stored on a Windows Server 2003 R2 file share, using the file:// protocol.
Have you considered running svnserve on that Windows Server 2003 box and then accessing the repository from your client machines via the svn:// protocol?
This will require either re-checking-out working copies on the client machines or updating their URLs with svn switch --relocate (or through TortoiseSVN).
Nathan
Re: Windows 10 November 2019 security updates affecting file:// to
Win2003 shares?
Posted by Branko Čibej <br...@apache.org>.
On 20.11.2019 18:57, Nathan Hartman wrote:
> On Wed, Nov 20, 2019 at 10:59 AM jimbobmcgee
> <users~subversion.apache.org@jimbobmcgee.com
> <ma...@jimbobmcgee.com>> wrote:
>
> HI all;
>
> Appreciating the woefully out-of-date/unsupported nature of my
> setup, I thought it might be worth dropping a line to see if
> anyone else out there might be experiencing issues since this
> month's Patch Tuesday release.
>
> Prior to the November 2019 updates, our Windows 10 users were
> successfully using Subversion and/or TortoiseSVN to commit to some
> old v1.6 repositories stored on a Windows Server 2003 R2 file
> share, using the file:// protocol.
>
>
> Have you considered running svnserve on that Windows Server 2003 box
> and then accessing the repository from your client machines via the
> svn:// protocol?
>
> This will require either re-checking-out working copies on the client
> machines or updating their URLs with
No, just pointing to the new URL will be enough.
> svn switch --relocate (or through TortoiseSVN).
2. The '--relocate' option is deprecated. This syntax is equivalent to
'svn relocate FROM-PREFIX TO-PREFIX [PATH]'.
So, 'svn relocate', not 'svn switch --relocate'. :)
-- Brane
Re: Windows 10 November 2019 security updates affecting file:// to
Win2003 shares?
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Nov 20, 2019 at 10:59 AM jimbobmcgee <users~
subversion.apache.org@jimbobmcgee.com> wrote:
> HI all;
>
> Appreciating the woefully out-of-date/unsupported nature of my setup, I
> thought it might be worth dropping a line to see if anyone else out there
> might be experiencing issues since this month's Patch Tuesday release.
>
> Prior to the November 2019 updates, our Windows 10 users were successfully
> using Subversion and/or TortoiseSVN to commit to some old v1.6 repositories
> stored on a Windows Server 2003 R2 file share, using the file:// protocol.
Have you considered running svnserve on that Windows Server 2003 box and
then accessing the repository from your client machines via the svn://
protocol?
This will require either re-checking-out working copies on the client
machines or updating their URLs with svn switch --relocate (or through
TortoiseSVN).
Nathan
Re: Windows 10 November 2019 security updates affecting file:// to
Win2003 shares?
Posted by Branko Čibej <br...@apache.org>.
On 20.11.2019 16:17, jimbobmcgee wrote:
> HI all;
>
> Appreciating the woefully out-of-date/unsupported nature of my setup, I thought it might be worth dropping a line to see if anyone else out there might be experiencing issues since this month's Patch Tuesday release.
>
> Prior to the November 2019 updates, our Windows 10 users were successfully using Subversion and/or TortoiseSVN to commit to some old v1.6 repositories stored on a Windows Server 2003 R2 file share, using the file:// protocol. After the November 2019 updates, they are now all told that we "Can't write '/pathto/repo/db/txn-current' atomically: Permission denied" (paraphrased).
>
> No changes were made to the Windows Server (i.e. this isn't a case of the permissions being changed on the server without our knowing).
>
> Running a Procmon (SysInternals) trace during the commit process suggests that the updated Win10 clients are getting a different behaviour when the txn-HEX file is renamed to txn-current. Procmon reports that a SetRenameInformationFile operation gets a 0xC00000D5 error, where not-updated clients do not get an error.
>
> I can't find much on the error code 0xC00000D5, except in a NTSTATUS values reference, where it suggests that the source file might already have been renamed.
>
> We've tried here with svn.exe builds (from sliksvn.com) and TortoiseSVN builds at both v1.11.1 and v1.13.0. Commits to another Win2008R2 server are successful, as are commits from anyone who hasn't installed the November 2019 updates.
>
> Not expecting anything to be done to support such an old setup, of course -- we have now moved all our repositories to another server -- but I thought I'd see if anyone else was experiencing the same issue? At least it might be searchable for future generations!
This is actually interesting, and thanks for describing the issue. It
appears that Windows is not backward-compatible with itself. :)
-- Brane