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
