From: Corinna Vinschen <corinna-cygwin@cygwin.com>
Subject: Re: New platform independent problem
Date: Fri, 20 Jan 2006 13:25:59 +0100 [thread overview]
Message-ID: <20060120122559.GZ8318@calimero.vinschen.de> (raw)
In-Reply-To: <ur773qhq5.fsf@gnu.org>
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
next prev parent reply other threads:[~2006-01-20 12:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-20 5:47 New platform independent problem djh
2006-01-20 11:08 ` Eli Zaretskii
2006-01-20 12:25 ` Corinna Vinschen [this message]
2006-01-20 13:59 ` Eric Blake
2006-01-20 14:14 ` Corinna Vinschen
2006-01-20 13:29 ` Igor Peshansky
2006-01-20 13:56 ` Eli Zaretskii
2006-01-20 14:18 ` Eric Blake
2006-01-20 16:48 ` Eli Zaretskii
2006-01-20 21:24 ` Andreas Schwab
2006-01-20 14:21 ` Corinna Vinschen
2006-01-27 20:45 ` Eli Zaretskii
2006-02-23 9:20 ` djh
-- strict thread matches above, loose matches on Subject: below --
2006-01-20 17:01 Eric Blake
2006-01-20 17:22 ` Eli Zaretskii
2006-01-28 14:18 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060120122559.GZ8318@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin@cygwin.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).