[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: Windows Server 2012 NTFS Deduplication, Special Status has Changed

From: Duncan Booth <duncan.booth_at_suttoncourtenay.org.uk>
Date: Fri, 19 Oct 2012 13:44:08 +0000 (UTC)

=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane_at_wandisco.com> wrote:

> On 19.10.2012 04:41, Josh Rowe wrote:
>> I didn't see this reported in the bug database, nor did a casual web
>> search turn this up:
>> When de-duplication is enabled on a Windows Server 2012 NTFS volume,
>> the de-duplication engine replaces files that contain duplicate data
>> with reparse points. Subversion then reports that those files have
>> unexpectedly changed special status. For example:
>> PS I:\temp\packages-2> svn commit
>> svn: E145001: Commit failed (details follow):
>> svn: E145001: Entry
>> 'I:\temp\packages-2\Roslyn.Compilers.VisualBasic.1.2.20906.2\lib
>> \Roslyn.Compilers.VisualBasic.dll' has unexpectedly changed special
>> status
>> Once the files have been deduplicated, the workaround is to disable
>> deduplication on a folder, then copy the versioned controlled
>> directory to the new location.
>> Repro steps:
>> Enable deduplication on a Win2012 NTFS volume.
>> Check out two copies of a repository onto the deduplicated volume.
>> Wait for deduplication to occur, or force it to happen.
>> Make a change to one copy of the repository.
>> Attempt to commit with "svn commit".
> This is not a Subversion bug. If the user tells NTFS to replace files
> with application-visible symbolic links, which apparently is what NTFS
> deduplication does, then there's hardly a sane way for Subversion to
> know that the user didn't do this intentionally.
Symbolic links in Windows are reparse points, but not all reparse points
are symbolic links. The de-duplication appears to use a specific data
deduplication type of reparse point, so Subversion could make the
distinction in a perfectly sane manner.

Every reparse point has an identifier tag identifying the type of
reparse point which includes the following possible values:

(other values are also possible as Microsoft provide a mechanism for
defining new tags)

If Subversion treated the IO_REPARSE_TAG_SYMLINK as a symlink and any
other type as a normal file that might be a sane solution.

It is unfair to blame the user: the user may not have control over the
settings an administrator makes for the server file system. There is a
workaround (have Subversion checkouts excluded from deduplication by
policy) but that assumes the administrator of the server is willing to
make appropriate policy changes.
Received on 2012-10-19 15:45:03 CEST

This is an archived mail posted to the Subversion Dev mailing list.