This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New platform independent problem


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 1/20/2006 5:25 AM:
> 
> I'm also having a problem right now building rcp and scp due to the
> missing d_ino.  OTOH, the d_ino member is not required by POSIX, but
> only in X/Open compliant OSes, see
> 
>   http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
>   http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_01_04
> 
> So, portable applications shouldn't rely on d_ino.

Is there a compromise here?  Many applications that look at d_ino also
check whether the d_ino member is 0, in which case they fall back on
st_ino.  For example, coreutils's pwd.c contains:

#define NOT_AN_INODE_NUMBER 0
#ifdef D_INO_IN_DIRENT
# define D_INO(dp)((dp)->d_ino)
#else
/* Some systems don't have inodes, so fake them to avoid lots of ifdefs.  */
# define D_INO(dp) NOT_AN_INODE_NUMBER
#endif

Then later on, it can blindly do:

ino_t ino = D_INO(dp);
if (ino == NOT_AN_INODE_NUMBER)
  {
    if (lstat (dp->d_name, &ent_sb) < 0)
      continue; /* Skip any entry we can't stat.  */
    ino = ent_sb.st_ino;
  }

> 
> Whether we should revert to using d_ino or not, I'm not sure.  From a
> Windows perspective, it's a step in the right direction.  From an
> application portability perspective, it should be ok to do it.  From a
> Linux compatibility perspective, which we claim, it might be somewhat
> hazardous to drop d_ino, though.

This would allow cygwin to provide the d_ino member (but probably in a new
offset, rather than renaming __deprecated_d_ino back to d_ino, to avoid
breaking backwards compatibility with old cygwin apps that have come to
rely on the field at offset __deprecated_d_ino being a hash rather than an
inode value).  Cygwin would then set it to 0 on WinNT and 2k (where it is
prohibitively expensive to determine a real value), set it to the hash on
Win9x and ME (since st_ino is also the hash on those platforms), and set
it to the actual st_ino value on WinXP and beyond (since the API exists).

It would just be a matter of educating apps that use d_ino that when
d_ino==0, fall back on st_ino instead.  And based on the code in
coreutils, this is probably already the case for code that strives to be
portable, since it appears there are already existing Unix machines that
return d_ino == 0 when a real value is not available.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD0Oyk84KuGfSFAYARArXgAJ0aQu09wfK4ab0R+upRH7kLq6FlTACgluSD
Y8hqZD9P15tdhF6v2Rv2sXY=
=+rha
-----END PGP SIGNATURE-----

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]