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 and Data Deduplication (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
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.
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