Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares?

[Branko Čibej]

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 0xC0D5 error, where not-updated 
> clients do not get an error.
>
> I can't find much on the error code 0xC0D5, 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

Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares?

[Branko Čibej]

On 20.11.2019 18:57, Nathan Hartman wrote:
> On Wed, Nov 20, 2019 at 10:59 AM 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.  
>
>
> 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?

[Nathan Hartman]

On Wed, Nov 20, 2019 at 2:21 PM jimbobmcgee  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?

[jimbobmcgee]

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 
To: jimbobmcgee 
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 
 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?

[Nathan Hartman]

On Wed, Nov 20, 2019 at 10:59 AM 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.


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

Windows 10 November 2019 security updates affecting file:// to Win2003 shares?

[jimbobmcgee]

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 0xC0D5 error, where not-updated 
clients do not get an error.

I can't find much on the error code 0xC0D5, 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: "svn diff -c" behavior on file copy from an old revision

[Johan Corveleyn]

On Tue, Nov 19, 2019 at 4:53 PM Nathan Hartman  wrote:
>
> On Mon, Nov 18, 2019 at 4:44 AM Vincent Lefevre  
> wrote:
>>
>> I have the following issue with svn 1.10.6:
>>
>> Assume that I committed "file1" at revision 1, did some unrelated
>> change at revision 2, and for revision 3, copied "file1@1" to "file2"
>> with "svn copy"[*] and did some changes in file2 before the commit.
>>
>> [*] The revision older than the latest one is what happens when one
>> does a "svn copy" directly from the working copy without an update
>> first.
>>
>> If I do "svn diff -r 1:3 file2", then I get the changes that have been
>> introduced between file1 and file2. But if I do "svn diff -c 3 file2",
>> which is equivalent to "svn diff -r 2:3 file2", then I get the whole
>> file2 content, as if file2 were an entirely new file.
>>
>> I'm wondering whether this is the expected behavior. In any case,
>> this behavior is rather unintuitive and rather useless. I think there
>> should be an easy way to get the changes introduced by a commit.

[ snipped note ... not sure this is the same problem, see below. ]

>
>
> Hello Vincent,
>
> Thank you for reporting this.
>
> I think it is the expected behavior because file2 does not exist in revision 
> 2 and by using '-c 3' (equivalent to -r 2:3) you're restricting the revisions 
> that are included in the differencing; as it does not follow the copy source 
> farther back than revision 2, the file is considered a new file.
>
> In contrast, with -r 1:3, since the revisions are not restricted (or at least 
> not as restricted; revision 1 is now included in the differencing), it 
> follows the copy backwards to revision 1 and shows only the differences.
>
> I agree it would be nice if it could show only the changes in the copy, but 
> then a command like 'diff -r 2:3' would be ambiguous... How would it know if 
> you want it to trace history beyond the range specified, or if you want it to 
> respect the -r 2:3 limit?
>
> Thoughts?

This issue is _ancient_ :-).

FWIW: I agree with you, Vincent. I expect the same behavior as you do.
But this has been discussed at length before, and so far no one has
managed to (find consensus to) change this, or to even invent a new
option to get the behavior you and I find intuitive.

For some background, see this thread from dev@ in 2013 [1]:
1.6 vs. 1.8: strange behavior of 'svn diff -cN WC-FILE' if the
file was created in rev N by copying

In my last post in that thread I tried the "but this is inconsistent /
unpredictable" card, to no avail [2]:
"Maybe I gave the wrong impression, but I'm not trying to completely
 redefine the behavior of 'diff -c'. However the current behavior, when
 looking at a moved file, is unpredictable: it depends on whether or
 not the move source's revision was exactly 1 revision before the
 move-commit. That unpredictability is not good."

Somewhere in that thread I also dropped a pointer to an earlier thread
in which I observed (in passing) that this was a difference between
'svn' and 'svnlook' [3].
"So it seems that detecting copies with their sources is broken in
'svn diff'"

[1] https://svn.haxx.se/dev/archive-2013-06/0588.shtml
[2] https://svn.haxx.se/dev/archive-2013-06/0705.shtml
[3] https://svn.haxx.se/dev/archive-2012-11/0480.shtml


Vincent Lefevre also wrote:
>> Note: "svn cat -r... file2" or "svn cat -r... file2@3" also shows a
>> similar behavior:
>>   -r1: one gets file1@1
>>   -r2: "Unable to find repository location for..." error
>>   -r3: one gets file2@3

Hm, it might be related, but I don't see this as exactly the same
problem. IMHO this is normal and correct behavior.

Indeed, in r2 there was no file2. In r1 there was a predecessor of
file2@3, namely file1@1. You could argue that in r2 it should show the
contents of file1@1 (which were incidentally unchanged in r2). But
what if file1 would have been changed in r2 (yet file2@3 was a copy of
file1@1), what would you expect svn to show? Or what if file1 was
deleted in r2?

I guess the same questions can be asked for 'svn diff -c 3' (what if
file1 had a different content in r2, or was deleted in r2?). Yet in
that case I intuitively expect "diff -c3" to take the copy-source into
account, no matter if it has made a jump through history. As I argued
in [3] above, it seems 'svnlook' can do this with its --diff-copy-from
option ... (which I happen to like for generating diffs in post-commit
emails).

-- 
Johan