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
Received on 2019-11-21 08:11:29 CET