Re: FW: Windows. Git, and Dedupe

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Mar 19, 2013, 21:08 UTC
Message-ID: <5148D3BD.4040608@lsrfire.ath.cx>
In-Reply-To: <02803146dc74414191fab53b0de33fa1@BLUPR03MB019.namprd03.prod.outlook.com>

Am 18.03.2013 22:20, schrieb Josh Rowe:

Show 6 quoted lines

> On Windows with an NTFS volume with Deduplication enabled, Git
> believes that deduplicated files are symlinks.  It then fails to be
> able to do anything with the file.  This can be repro-ed by creating
> an NTFS volume with dedup, creating some duplicate files, verifying
> that a few files are deduped, and trying to add and commit the files
> via git.

Both Single Instance Storage[1] and Data Deduplication[2] (introduced with Windows Server 2012) seem to be server-only features. How about keeping regular git repositories with checked-out files on client disks and use the server only for bare repositories (without working tree)?

When I tried to add a symbolic link created with mklink on Windows 8, the mingw version of git refused because readlink(2) is not supported. This seems to be sufficient to reproduce the issue.

I couldn't test the Cygwin version, though, because http://cygwin.com doesn't respond at the moment.

But a working readlink(2) wouldn't help anyway, I guess. I imagine that the reparse points used for deduplication point into a magic block store which performs garbage collection of content that is no longer referenced -- which probably means that a recreated "symlink" may point to blocks that have been deleted in the meantime.

Perhaps you need a way to ask git to always follow symlinks instead of trying to store their target specification.

René

[1] http://technet.microsoft.com/en-us/library/dd573308%28v=ws.10%29.aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/hh769303%28v=vs.85%29.aspx