RE: FW: Windows. Git, and Dedupe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.  

I'm using:

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.  

Jmr


-----Original Message-----
From: René Scharfe [mailto:rene.scharfe@xxxxxxxxxxxxxx] 
Sent: Wednesday, March 20, 2013 12:55 PM
To: Josh Rowe
Cc: git@xxxxxxxxxxxxxxx; msysgit@xxxxxxxxxxxxxxxx
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, but still.

> 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 [1] 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?

Thanks,
René


[1] https://git.kernel.org/cgit/git/git.git/tree/compat/mingw.c#n427



��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]