Thread (6 messages) flat view 6 messages, 2 authors, 2016-06-15

Re: FW: Windows. Git, and Dedupe

From: René Scharfe <hidden>
Date: 2016-06-15 22:56:27

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help