If you have Win8 or HyperV 2012, I can ship you a small NTFS .vhd with some
deduped files. I'm not sure if that will be readable, but I would hazard a
guess that it would be. It definitely will not be readable on Win7.
PS C:\> git version
git version 1.8.0.msysgit.0
I don't see any changes related to this in the file log since the original code
was added in 2010. I do notice that mingw_fstat doesn't do anything special
with symlinks; I don't know where that is used.
The file sizes show up as their original size with Windows tools (powershell,
Win32, cmd, .Net, etc). git ls-tree -r HEAD does not show that hash code for
files that are not intentionally empty.
From: René Scharfe [mailto:rene.scha...@lsrfire.ath.cx]
Sent: Wednesday, March 20, 2013 12:55 PM
To: Josh Rowe
Cc: email@example.com; msys...@googlegroups.com
Subject: Re: FW: Windows. Git, and Dedupe
Am 19.03.2013 22:36, schrieb Josh Rowe:
> Yes, Dedup is in fact a Server-only feature.
Is there an easier way to reproduce the issue than registering and downloading
the Windows Server 2012 evaluation version? It's not that hard, admittedly,
> The reparse point could be decoded as being a non-symlink reparse
> itemusing; in those cases, treating the file as an "ordinary"
> file would be appropriate.
> For example, see the following. The reparse tag value for symlinks
> isIO_REPARSE_TAG_SYMLINK (0xa000000c) and for deduped files is
> (IO_REPARSE_TAG_DEDUP) 0x80000013.
That's interesting and invalidates my initial checks with mklink, because if I
read compat/mingw.c  correctly then git handles symlinks on Windows in a
special way, but should treat dedup reparse points as normal files already.
Hrm, but probably st_size is set to zero for them. Do the deduped files appear
as empty? "git ls-tree -r HEAD" would show them with a hash of
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391. If true then how do we get their
real content sizes using Win32 API calls?
By the way, what does the command "git version" return for you?