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

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
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
More majordomo info at

Reply via email to