Re: question on d_ino semantics

[Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>]

On Sat, Jan 21, 2006 at 08:45:52AM -0600, * * wrote:
>On 1/20/06, Eric Blake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> There are currently two competing uses of d_ino semantics in coreutils:
>>
>> lib/backupfile.c assumes that if d_ino is ever 0, (captured by the macro
>> REAL_DIR_ENTRY, which is always non-zero on platforms without d_ino), that
>> readdir() returned an invalid entry and no attempt to dereference that
>> name should be attempted.
>>
>> src/pwd.c assumes that if d_ino is ever 0, (captured by the macro D_INO,
>> which is hardcoded to 0 on platforms without d_ino), that an lstat()
>> should be attempted and the entry skipped if the stat failed, otherwise
>> use st_ino.
>>
>> Cygwin currently has no d_ino member, because it is prohibitively
>> expensive to provide it on WinNT and Win2K machines (the only way to make
>> d_ino match st_ino on those two platforms is to perform the equivalent of
>> a stat during readdir, but this penalizes the many apps which do not
>> follow readdir with stat).  But it is relatively trivial to provide d_ino
>
>In any other language.... this would be fairly easy.  Make d_ino a
>postponed call / functor that calls stat if and only if it is read. 
>Even with C++ this is possible.  Is there any way for Cygwin to change
>d_ino into some type of function call which can perform the processing
>*on access*.

I actually spent some time yesterday implementing something like this
but it is very tricky to get right.  The thing that seems to be lost in
the noise here is that some applications are using d_ino in a way that
makes no sense for Windows.

I had a discussion about this in the git mailing list.  They were using
d_ino to sort update requests since, clusters of inodes are apt to be
located close to each other on disk.  Windows makes no such guarantee,
though.  I wonder if other applications are making similar assumptions
and possibly would benefit from some code inspection and a "#ifdef __CYGWIN__".

I hate to admit defeat about things like this but it really seems to me
that this is one of those cases where the code has to be modified to work
correctly on Windows/Cygwin.  Inodes are a low-level detail on linux
which we will never be able to get 100% right on cygwin.

>Of course, this would be totally incompatible with anything that tries
>to take the address of d_ino or write to it, but from the discussion,
>that seems to be 0% of callers.

But there are certainly applications which have variables called "d_ino".
They would have to be changed.

Btw, the latest snapshot implements "__USE_EXPENSIVE_CYGWIN_D_INO".
If this is defined, then d_ino will be defined and filled out with the
same inode information as derived by lstat().

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/