Am 18.03.2013 22:20, schrieb Josh Rowe:
> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to