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
