=?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
\net45
>> \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:
IO_REPARSE_TAG_CSV
IO_REPARSE_TAG_DEDUP
IO_REPARSE_TAG_DFS
IO_REPARSE_TAG_DFSR
IO_REPARSE_TAG_HSM
IO_REPARSE_TAG_HSM2
IO_REPARSE_TAG_MOUNT_POINT
IO_REPARSE_TAG_NFS
IO_REPARSE_TAG_RESERVED_ONE
IO_REPARSE_TAG_RESERVED_RANGE
IO_REPARSE_TAG_RESERVED_ZERO
IO_REPARSE_TAG_SIS
IO_REPARSE_TAG_SYMLINK
IO_REPARSE_TAG_WIM
(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