New platform independent problem

New platform independent problem

[djh]

In December of last year, 2005, the cygwin developers deprecated d_ino 
out of the dirent.h defined dirent structure.  

This break emac's dired.c (from compiling)

Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html

This change causes a "make bootstrap" error in building my emacs vers. 
22.0.50 source.

"gcc -c  -Demacs -DHAVE_CONFIG_H -DUSE_GTK  -I. ..snipped...-O2 dired.c
dired.c: In function `directory_files_internal':
dired.c:230: error: structure has no member named `d_ino'
dired.c: In function `file_name_completion':
dired.c:538: error: structure has no member named `d_ino'
make[1]: *** [dired.o] Error 1 "

Under the prior version of cygwin this built successfully.

I unfortunatley am not expert enough to suggest any fixes for this, but, 
I wanted to bring it to your attension to those of you out there who are 
and want emacs to continue to be usable on the newer version of cygwin.

Regards,
   Darel Henman

Re: New platform independent problem

[Eli Zaretskii]

> Date: Fri, 20 Jan 2006 14:47:40 +0900
> From: djh <henman@it.to-be.co.jp>
> 
> In December of last year, 2005, the cygwin developers deprecated d_ino 
> out of the dirent.h defined dirent structure.  
> 
> This break emac's dired.c (from compiling)
> 
> Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html

Without knowing the full details, I'd risk saying that this was not
the best decision.  Is there really no way of making d_ino be
consistent with what `stat' returns about the same directory?

In any case, I think removing the member is a solution that is much
worse than the problem: many programs refer to d_ino, but don't
require too much from its contents.  These programs will now fail to
compile.  I don't think that the goal of educating the maintainers of
Bash and Find (a worthy goal in itself) justifies breaking the other
packages.

If making d_ino consistent with st_ino is impossible, a better way of
dealing with problems in Bash and Find is to make changes in those
packages' sources that are specific to Cygwin.

> This change causes a "make bootstrap" error in building my emacs vers. 
> 22.0.50 source.
> 
> "gcc -c  -Demacs -DHAVE_CONFIG_H -DUSE_GTK  -I. ..snipped...-O2 dired.c
> dired.c: In function `directory_files_internal':
> dired.c:230: error: structure has no member named `d_ino'
> dired.c: In function `file_name_completion':
> dired.c:538: error: structure has no member named `d_ino'
> make[1]: *** [dired.o] Error 1 "
> 
> Under the prior version of cygwin this built successfully.
> 
> I unfortunatley am not expert enough to suggest any fixes for this, but, 
> I wanted to bring it to your attension to those of you out there who are 
> and want emacs to continue to be usable on the newer version of cygwin.

The immediate fix seems to be to modify the definition of
DIRENTRY_NONEMPTY for Cygwin so that it uses the same trick as on
MS-DOS.  (Isn't it sad that Cygwin needs old MS-DOS era tricks?)

Re: New platform independent problem

[Corinna Vinschen]

On Jan 20 13:08, Eli Zaretskii wrote:
> > Date: Fri, 20 Jan 2006 14:47:40 +0900
> > From: djh 
> > 
> > In December of last year, 2005, the cygwin developers deprecated d_ino 
> > out of the dirent.h defined dirent structure.  
> > 
> > This break emac's dired.c (from compiling)
> > 
> > Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html
> 
> Without knowing the full details, I'd risk saying that this was not
> the best decision.  Is there really no way of making d_ino be
> consistent with what `stat' returns about the same directory?

The problem is that the Windows functions for reading directory content
don't return the inode number(*), so we ended up using a namehash for
the d_ino member.  Otherwise, to get the inode number for the files'
directory entry, we would have to open each file to get a handle, then
call GetFileInformationByHandle, and then have to close the handle
again.  This would make the readdir function *very* slow.

The other alternative would be to use always a namehash, also in the
st_ino case.  The problem with this approach is that hardlinks to the
same file would have different inode numbers, which then confuse tar or
cpio.

> In any case, I think removing the member is a solution that is much
> worse than the problem: many programs refer to d_ino, but don't
> require too much from its contents.  These programs will now fail to
> compile.  I don't think that the goal of educating the maintainers of
> Bash and Find (a worthy goal in itself) justifies breaking the other
> packages.
> 
> If making d_ino consistent with st_ino is impossible, a better way of
> dealing with problems in Bash and Find is to make changes in those
> packages' sources that are specific to Cygwin.

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.

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.


Corinna

(*) Beginning with Windows XP, two such functions exist now, but they
    won't help for older OSes, obviously.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: New platform independent problem

[Eric Blake]

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

Re: New platform independent problem

[Corinna Vinschen]

[Resent to add emacs-devel and Eli on the "To:" list]

On Jan 20 06:59, Eric Blake wrote:
> 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;
>   }

Well, other applications like rcp and scp just use d_ino to check for 0
and to ignore it entirely then, like this:

  while (readdir)
    {
      if (d_ino == 0)
        continue;
      [...action...]
    }

This means, if d_ino is 0, it breaks scp and rcp and some other
applications.  If it's always some arbitrary non-zero value, it breaks
pwd from coreutils and some other applications.  If it's available and
doesn't match st_ino, it breaks another set of applications.  If it's
not available at all, it breaks all applications asking for d_ino in any
way. 

> 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).

That would be a better solution, though it would still not be ok to set
it to 0 on NT4 and 2K.  Maybe we should think about another way to
generate a hash value and use it on all platforms.  I'm just at a loss
right now, to come up with another hash generation method, which would
allow to get the same inode number for hardlinks :-(


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: New platform independent problem

[Igor Peshansky]

On Fri, 20 Jan 2006, Eli Zaretskii wrote:

> > Date: Fri, 20 Jan 2006 14:47:40 +0900
> > From: djh <henman@XX.XX-XX.XX.XX>
> >
> > In December of last year, 2005, the cygwin developers deprecated d_ino
> > out of the dirent.h defined dirent structure.

...changing it to __deprecated_d_ino, I believe.

> > This break emac's dired.c (from compiling)
> > Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html
>
> Without knowing the full details, I'd risk saying that this was not
> the best decision.  Is there really no way of making d_ino be
> consistent with what `stat' returns about the same directory?

Corinna already covered that.

> In any case, I think removing the member is a solution that is much
> worse than the problem: many programs refer to d_ino, but don't
> require too much from its contents.  These programs will now fail to
> compile.  I don't think that the goal of educating the maintainers of
> Bash and Find (a worthy goal in itself) justifies breaking the other
> packages.
>
> If making d_ino consistent with st_ino is impossible, a better way of
> dealing with problems in Bash and Find is to make changes in those
> packages' sources that are specific to Cygwin.

Frankly, many programs expect that if d_ino is present, it has the correct
value (i.e., the same as st_ino).  Having the member and not setting it
correctly is essentially lying to the application.  Is it so bad for
Cygwin to be honest?

> > This change causes a "make bootstrap" error in building my emacs vers.
> > 22.0.50 source.
> >
> > "gcc -c  -Demacs -DHAVE_CONFIG_H -DUSE_GTK  -I. ..snipped...-O2 dired.c
> > dired.c: In function `directory_files_internal':
> > dired.c:230: error: structure has no member named `d_ino'
> > dired.c: In function `file_name_completion':
> > dired.c:538: error: structure has no member named `d_ino'
> > make[1]: *** [dired.o] Error 1 "
> >
> > Under the prior version of cygwin this built successfully.
> >
> > I unfortunatley am not expert enough to suggest any fixes for this,
> > but, I wanted to bring it to your attension to those of you out there
> > who are and want emacs to continue to be usable on the newer version
> > of cygwin.
>
> The immediate fix seems to be to modify the definition of
> DIRENTRY_NONEMPTY for Cygwin so that it uses the same trick as on
> MS-DOS.  (Isn't it sad that Cygwin needs old MS-DOS era tricks?)

If the content of d_ino isn't required to be anything specific, a simpler
solution could be something like

#ifdef __CYGWIN__
#define d_ino __deprecated_d_ino
#endif

Though why would a program refer to d_ino if it doesn't expect to do
anything with its content is beyond me.
HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

Re: New platform independent problem

[Eli Zaretskii]

> Date: Fri, 20 Jan 2006 08:29:20 -0500 (EST)
> From: Igor Peshansky <pechtcha@cs.nyu.edu>
> cc: djh <henman@it.to-be.co.jp>, emacs-devel@gnu.org, cygwin@cygwin.com
> 
> > > This break emac's dired.c (from compiling)
> > > Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html
> >
> > Without knowing the full details, I'd risk saying that this was not
> > the best decision.  Is there really no way of making d_ino be
> > consistent with what `stat' returns about the same directory?
> 
> Corinna already covered that.

Where?  I don't see anything from Corinna in the thread that followed
the above message.  (I don't read the Cygwin list.)

> Frankly, many programs expect that if d_ino is present, it has the correct
> value (i.e., the same as st_ino).

Which programs expect that, besides the two Chris mentioned?  My
experience is the other way around: that d_ino is rarely used.

> Having the member and not setting it correctly is essentially lying
> to the application.  Is it so bad for Cygwin to be honest?

What is bad is to have dirent.h, but not some of the struct members it
calls for.

> If the content of d_ino isn't required to be anything specific, a simpler
> solution could be something like
> 
> #ifdef __CYGWIN__
> #define d_ino __deprecated_d_ino
> #endif

It's bad mantra for an application to use a symbol that starts with
"__", since those symbols are reserved for the library implementation.

> Though why would a program refer to d_ino if it doesn't expect to do
> anything with its content is beyond me.

Emacs cares that d_ino is non-zero, meaning that this direntry is not
empty, but otherwise the value of d_ino is not important.

Re: New platform independent problem

[Eric Blake]

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

According to Eli Zaretskii on 1/20/2006 6:56 AM:
> 
>>Frankly, many programs expect that if d_ino is present, it has the correct
>>value (i.e., the same as st_ino).
> 
> 
> Which programs expect that, besides the two Chris mentioned?

Several of the coreutils expect that if d_ino is non-zero, it matches
st_ino.  This is in addition to findutils and bash.  But it is probably as
easy to teach programs that a sentinel value means fall back on st_ino as
it is to teach programs to not expect d_ino to exist.

>  My
> experience is the other way around: that d_ino is rarely used.

Which is why it is prohibitively expensive for cygwin to populate it with
the correct value on WinNT and Win2K; too few applications use d_ino to
make it worth doing the Windows equivalent of stat during the readdir() to
correctly populate the d_ino member.  But if we are going to populate
d_ino, it had better either be st_ino (so we aren't lying), or a sentinel
that makes it obvious that st_ino should be used instead (either 0 or -1).
 Fortunately, Win9x and WinXP had non-prohibitive costs to making d_ino
match st_ino.

> 
> 
>>Having the member and not setting it correctly is essentially lying
>>to the application.  Is it so bad for Cygwin to be honest?
> 
> 
> What is bad is to have dirent.h, but not some of the struct members it
> calls for.

POSIX permits implementations to not have d_ino.  In other words, when it
comes to dirent.h, cygwin is fully POSIX-compliant to not have a d_ino
member, and applications had better not assume that d_ino exists.

> 
> It's bad mantra for an application to use a symbol that starts with
> "__", since those symbols are reserved for the library implementation.

My understanding is that leading __ is reserved for the IMPLEMENTATION in
general, not just the library implementation; cygwin is part of the
implementation.  The goal here it to make sure that cygwin does not
pollute the namespace of a compliant app, since the rule is that a
compliant app can use any symbol not reserved by the standards that does
not start with __ without worry of conflict.  And no one has complained
yet that __deprecated_d_ino causes a conflict to a library.

> 
> 
>>Though why would a program refer to d_ino if it doesn't expect to do
>>anything with its content is beyond me.
> 
> 
> Emacs cares that d_ino is non-zero, meaning that this direntry is not
> empty, but otherwise the value of d_ino is not important.

What platforms use d_ino==0 to mean an empty entry, rather than an entry
where st_ino must be checked?  Is it worth introducing -1 as the cygwin
sentinel for non-empty entry, but where st_ino must be consulted, rather
than 0 as the sentinel?

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

iD8DBQFD0PEq84KuGfSFAYARApZPAJ9jDeUsHhMB59OIDUSzoqyhnSIrHACePz0F
/ENdWA/qbuGIYpCIEpKAv9A=
=gySC
-----END PGP SIGNATURE-----

Re: New platform independent problem

[Eli Zaretskii]

> Date: Fri, 20 Jan 2006 07:18:18 -0700
> From: Eric Blake <ebb9@byu.net>
> CC: cygwin@cygwin.com,  henman@it.to-be.co.jp,  emacs-devel@gnu.org
> 
> Which is why it is prohibitively expensive for cygwin to populate it with
> the correct value on WinNT and Win2K; too few applications use d_ino to
> make it worth doing the Windows equivalent of stat during the readdir() to
> correctly populate the d_ino member.  But if we are going to populate
> d_ino, it had better either be st_ino (so we aren't lying), or a sentinel
> that makes it obvious that st_ino should be used instead (either 0 or -1).
>  Fortunately, Win9x and WinXP had non-prohibitive costs to making d_ino
> match st_ino.

You could have a flag that, if set, will instruct readdir to do the
expensive processing.  Applications that need the real inode will set
that flag.

> > What is bad is to have dirent.h, but not some of the struct members it
> > calls for.
> 
> POSIX permits implementations to not have d_ino.  In other words, when it
> comes to dirent.h, cygwin is fully POSIX-compliant to not have a d_ino
> member, and applications had better not assume that d_ino exists.

That may be so, but I don't think I've seen packages that check
whether d_ino exist in their configury.  They assume it does, AFAICS.

> > It's bad mantra for an application to use a symbol that starts with
> > "__", since those symbols are reserved for the library implementation.
> 
> My understanding is that leading __ is reserved for the IMPLEMENTATION in
> general, not just the library implementation; cygwin is part of the
> implementation.

I was responding to a suggestion to use __deprecated_d_ino in the
Emacs code.  Emacs is certainly _not_ a part of implementation.

> What platforms use d_ino==0 to mean an empty entry, rather than an entry
> where st_ino must be checked?

I see it in Emacs, Corinna shows another example from rcp and scp.

Re: New platform independent problem

[Andreas Schwab]

Eric Blake <ebb9@byu.net> writes:

> What platforms use d_ino==0 to mean an empty entry, rather than an entry
> where st_ino must be checked?

This is traditional Unix behaviour.  The original dirent structure (which
was actually struct direct from <sys/dir.h>) directly matched the contents
of the directory file on disk, and an entry was deleted by setting d_ino
to zero.  Modern implementations of the dirent functions hide this detail
from the user and never return entries with d_ino == 0 any more.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New platform independent problem

[Corinna Vinschen]

On Jan 20 15:56, Eli Zaretskii wrote:
> > From: Igor Peshansky 
> > > Without knowing the full details, I'd risk saying that this was not
> > > the best decision.  Is there really no way of making d_ino be
> > > consistent with what `stat' returns about the same directory?
> > 
> > Corinna already covered that.
> 
> Where?  I don't see anything from Corinna in the thread that followed
> the above message.  (I don't read the Cygwin list.)

http://cygwin.com/ml/cygwin/2006-01/msg00972.html, also sent to you in
PM, as well as to the emacs-devel list.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: New platform independent problem

[Eli Zaretskii]

> Date: Fri, 20 Jan 2006 14:47:40 +0900
> From: djh <henman@it.to-be.co.jp>
> 
> In December of last year, 2005, the cygwin developers deprecated d_ino 
> out of the dirent.h defined dirent structure.  
> 
> This break emac's dired.c (from compiling)
> 
> Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html
> 
> This change causes a "make bootstrap" error in building my emacs vers. 
> 22.0.50 source.
> 
> "gcc -c  -Demacs -DHAVE_CONFIG_H -DUSE_GTK  -I. ..snipped...-O2 dired.c
> dired.c: In function `directory_files_internal':
> dired.c:230: error: structure has no member named `d_ino'
> dired.c: In function `file_name_completion':
> dired.c:538: error: structure has no member named `d_ino'
> make[1]: *** [dired.o] Error 1 "

I installed a change in src/dired.c to avoid this problem.  Please try
the current CVS and see if the problem is gone.

Re: New platform independent problem

[djh]

Eli,
  terribly sorry for the response delay.

Eli Zaretskii wrote: (2006/01/28 5:45)
 >> djh wrote:
>>In December of last year, 2005, the cygwin developers deprecated d_ino 
>>out of the dirent.h defined dirent structure.  
>>
>>This break emac's dired.c (from compiling)
>>This change causes a "make bootstrap" error in building my emacs vers. 
>>22.0.50 source.
> 
  I installed a change in src/dired.c to avoid this problem.  Please try
  the current CVS and see if the problem is gone.

Yes, whatever you changed in src/dired.c, allows dired.c to be built, 
successfully.

Thanks,
   Darel Henman

Re: New platform independent problem

[Eric Blake]

> You could have a flag that, if set, will instruct readdir to do the
> expensive processing.  Applications that need the real inode will set
> that flag.

And then we would have to change applications to call this nonstandard
entry point at the beginning of their program to set the flag.  As long
as we are editing programs, we might as well teach them to respect
a sentinel of -1 without having to resort to adding a nonstandard
entry point.

> > POSIX permits implementations to not have d_ino.  In other words, when it
> > comes to dirent.h, cygwin is fully POSIX-compliant to not have a d_ino
> > member, and applications had better not assume that d_ino exists.
> 
> That may be so, but I don't think I've seen packages that check
> whether d_ino exist in their configury.  They assume it does, AFAICS.

Most GNU packages DO check - coreutils, findutils, bash, tar, etc.  And
since POSIX makes it optional, ALL portable programs SHOULD check
for the existance of d_ino.  I was actually surprised that emacs does not.

> 
> > > It's bad mantra for an application to use a symbol that starts with
> > > "__", since those symbols are reserved for the library implementation.
> > 
> > My understanding is that leading __ is reserved for the IMPLEMENTATION in
> > general, not just the library implementation; cygwin is part of the
> > implementation.
> 
> I was responding to a suggestion to use __deprecated_d_ino in the
> Emacs code.  Emacs is certainly _not_ a part of implementation.

Correct.  But that wouldn't help you anyways - if you are using the
version of cygwin's dirent.h that spells it __deprecated_d_ino,
then you are also using the version of cygwin's version.h that
informs the cygwin1.dll to fill that entry with 0 rather than the hash.
In other words, cygwin is smart enough to know whether your
application was compiled with d_ino existance, and does not even
bother creating a non-zero __deprecated_d_ino.

> 
> > What platforms use d_ino==0 to mean an empty entry, rather than an entry
> > where st_ino must be checked?
> 
> I see it in Emacs, Corinna shows another example from rcp and scp.

And after further research, I have found that coreutils is inconsistent;
backupfile.c does it one way (0 means skip the entry, but don't care
if d_ino matches st_ino) while pwd.c does it another way (0 means
fall back to stat, so that result always matches st_ino, and skip
entry if stat also failed).  So now is the time to pick the behavior
that is easiest to turn into a reasonable coding standard across
all GNU platforms (and probably to add a gnulib module that
does the d_ino magic for you).

--
Eric Blake

Re: New platform independent problem

[Eli Zaretskii]

> From: ericblake@comcast.net (Eric Blake)
> Cc: cygwin@cygwin.com, henman@it.to-be.co.jp, emacs-devel@gnu.org
> Date: Fri, 20 Jan 2006 17:01:37 +0000
> 
> > You could have a flag that, if set, will instruct readdir to do the
> > expensive processing.  Applications that need the real inode will set
> > that flag.
> 
> And then we would have to change applications to call this nonstandard
> entry point at the beginning of their program to set the flag.

Not necessarily, you could do that in a static constructor in a
Cygwin-specific source file, far from the application's sources, which
will remain unpolluted.

> As long as we are editing programs, we might as well teach them to
> respect a sentinel of -1 without having to resort to adding a
> nonstandard entry point.

I don't see how this is better: -1 is an arbitrarily picked value,
with no relation to any standard.  Why should applications learn about
it?

Re: New platform independent problem

[Corinna Vinschen]

On Jan 20 19:22, Eli Zaretskii wrote:
> > From: Eric Blake
> > As long as we are editing programs, we might as well teach them to
> > respect a sentinel of -1 without having to resort to adding a
> > nonstandard entry point.
> 
> I don't see how this is better: -1 is an arbitrarily picked value,
> with no relation to any standard.  Why should applications learn about
> it?

FYI, I've applied a rather big patch which reintroduced d_ino and which
tries hard to generate correct (aka "identical to stat(2)") inode numbers
for d_ino on all systems.  This includes a slightly expensive method to
determine inode numbers in a couple of situations(*):

- local NTFS on NT4
- remote NTFS on Win2K
- remote NT4/Win2K NTFS on XP and above.

While I tried to optimize the expensive inode evaluation as much as
possible, a certain slow down in the above situations might have been
unavoidable.

For the adventurous of you, try the next developer's snapshot of Cygwin
from http://cygwin.com/snapshots/


Corinna


(*) For the curious, the above situations are determined by the
    OS support of the FileIdBothDirectoryInformation flag in calls
    to NtQueryDirectoryFile.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat