From: Jeff Hostetler <git@jeffhostetler.com>
Date: Sun, 05 Aug 2018 14:01:49 GMT
Subject: Re: [PATCH/RFC] clone: report duplicate entries on case-insensitive filesystems
Message-ID: <9eb6caf1-b4aa-766d-922e-b2b24b391b33@jeffhostetler.com>
In-Reply-To: <20180803185325.GA27977@sigill.intra.peff.net>



On 8/3/2018 2:53 PM, Jeff King wrote:
> On Fri, Aug 03, 2018 at 02:23:17PM -0400, Jeff Hostetler wrote:
> 
>>> Maybe. It might not work as ino_t. Or it might be expensive to get.  Or
>>> maybe it's simply impossible. I don't know much about Windows. Some
>>> searching implies that NTFS does have a "file index" concept which is
>>> supposed to be unique.
>>
>> This is hard and/or expensive on Windows.  Yes, you can get the
>> "file index" values for an open file handle with a cost similar to
>> an fstat().  Unfortunately, the FindFirst/FindNext routines (equivalent
>> to the opendir/readdir routines), don't give you that data.  So we'd
>> have to scan the directory and then open and stat each file.  This is
>> terribly expensive on Windows -- and the reason we have the fscache
>> layer (in the GfW version) to intercept the lstat() calls whenever
>> possible.
> 
> I think that high cost might be OK for our purposes here. This code
> would _only_ kick in during a clone, and then only on the error path
> once we knew we had a collision during the checkout step.
> 

Good point.

I've confirmed that the "file index" values can be used to determine
whether 2 path names are equivalent under NTFS for case variation,
final-dot/space, and short-names vs long-names.

I ran out of time this morning to search the directory for equivalent 
paths.  I'll look at that shortly.

Jeff