Re: mingw and same-inode

[Jim Meyering]

Eric Blake wrote:
> According to Jim Meyering on 9/24/2009 12:29 AM:
>>   bool same = false;
>>   ...
>>       same = SAME_INODE (source_dir_stats, dest_dir_stats);
>>       if (same < 0)
>>         same = (identical_basenames
>>                 && strcmp (source_basename, dest_basename) == 0);
>
> As written, it wouldn't have worked, anyways.  The idea is that "./file"
> and "/path/to/file" can be the same name, so we need more than a strcmp of
> the dirnames.  Rather, it needs a strcmp of the canonicalized names.  And
> since mingw doesn't have working canonicalize_file_name yet, it probably
> even means using getcwd/chdir(dirname)/getcwd/chdir(cwd) twice to
> determine the two names to compare.

Ugh.  The prospect of having to pull in all of those dependencies
for the measly "same" module, solely to accommodate mingw's
lack of inode numbers is disturbing.

>> Your new test, "same < 0" will never be true when
>> compiled on a system with proper "bool" support.
>
> I missed that too.  All the more reason that I reverted the patch.
>
>> Apparently, since your testing did not expose this flaw,
>> no tested use of same_name requires the new semantics of SAME_INODE.
>
> Correct - on mingw, I had tested the use of SAME_INODE, but not of
> same_name (it made a difference as to whether at_func2 mistakenly assumed
> two fds pointed to the same directory).  Fortunately, on every other
> platform, SAME_INODE is still 0 or 1 (mingw is the only platform where
> st_ino is always 0, and therefore SAME_INODE was returning 1 even when it
> should have returned 0, leading to the tri-state proposal in the first
> place).  I suppose that for mingw, I could also beef up SAME_INODE to
> return 0 instead of -1 if other reliable fields in st_ino, such as st_ctim
> or st_size, differ.  (Note that on mingw, st_ctim is mistakenly the file
> creation time, corresponding to birthtime in BSD stat, rather than the
> last metadata change time as per POSIX, but it still serves as a reliable
> indicator of different files).
>
>> If the tri-state test is required in only a few places,
>> how about using a new macro, say SAME_INODE_TRISTATE,
>> in just those few places?
>
> There's two categories of clients of SAME_INODE - those that want to do
> something if the files are provably the same (any where I changed to
> SAME_INODE()==1), but which behave correctly if the files are different or
> indeterminate; and those that want to do something if the files are
> provably different, but which behave correctly if the files are the same
> or indeterminate.  If SAME_INODE can be reached on mingw, then a decision
> about what to do in the indeterminate case is necessary, even if we can
> reduce the indeterminate result.

When I see the tentacles of this change reaching so deeply into the core
of gnulib and coreutils, I have to question whether it is worthwhile
to accommodate mingw's lack of inode numbers.

Opinions?