[bug-diffutils] bug#25814: bug#25814: Windows same_file macro is not reliable

[Kees Dekker]

> NTFS supports inodes; Cygwin uses them.  Just because Window's native
> stat() is broken does not mean NTFS is broken.

NTFS is not broken, but according to MSDN, it does not support inodes. The fact 
that Cygwin supports is, is more how Cygwin implemented fstat/struct fstat 
(more in the *NIX way). Since Cygwin is not an option for us (everything is 
native Windows/Visual Studio), it does not help me in saying 'Cygwin is a 
solution'. I know that the GNU guys like Cygwin, but on Windows, it is beyond 
reality to expect that Cygwin on Windows is a synonym to native Windows. It is 
not.

>> because not everything is POSIX), the same_file() macro (in system.h) is 
>> incorrect as st_ino (and probably st_dev) are meaningless.

>Rather, instead of ignoring inode, it would be nicer (but indeed a more
>complex task) to have gnulib work around window's broken stat() to
>provide a version that works instead.  It only matters for file systems
>that support hard links (like NTFS); on file systems like FAT that lack
>hard links, hard-coding that inodes don't work is okay, but on NTFS
>where hard-links are supported, treating same_file() as always returning
>0 gives wrong results.

>At any rate, this is an issue that needs to be resolved in gnulib, as
>more than just diffutils is affected by it.

I don't know how Cygwin implements stat(), but maybe they use something like 
GetFileInformationByHandle() (see: 
https://msdn.microsoft.com/nl-nl/library/windows/desktop/aa363788(v=vs.85).aspx).
 Anyhow, it would be a good idea to improve gnulib for support (if you like to 
corset Windows in a POSIX form), but the fix in diff is now very simple. Just 
rewrite the macros as I described before. For the longer term, it may be worth 
to wait for a gnulib fix, but that is (for me for now) too long to wait. I'm 
not understanding why returning 0 for same_file causes problems. It just 
results in an actual compare. That is some inefficiency, but not erroneous 
isn't it?

Regards,
Kees