From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#10733: 24.0.93; w32 file truncation Date: Mon, 06 Feb 2012 20:37:56 +0200 Message-ID: <83sjinbyez.fsf@gnu.org> References: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> <20120205.161623.484163522.Takaaki.Ota@am.sony.com> <83zkcwbo7t.fsf@gnu.org> <874nv45y9f.fsf@wanadoo.es> <87zkcw3pjf.fsf@wanadoo.es> <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1328553501 10023 80.91.229.3 (6 Feb 2012 18:38:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2012 18:38:21 +0000 (UTC) Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 06 19:38:18 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RuTSC-0007Gu-Mq for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2012 19:38:16 +0100 Original-Received: from localhost ([::1]:60015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuTSC-0002C5-8P for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2012 13:38:16 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuTS9-0002Bz-AN for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:38:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuTS7-00019S-LX for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:38:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuTS7-00019M-Fi for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:38:11 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RuTSw-00053k-B7 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10733 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132855354019440 (code B ref 10733); Mon, 06 Feb 2012 18:39:02 +0000 Original-Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 18:39:00 +0000 Original-Received: from localhost ([127.0.0.1]:57520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuTSs-00053S-3G for submit@debbugs.gnu.org; Mon, 06 Feb 2012 13:39:00 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44695) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuTSm-00053C-JL for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 13:38:57 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LYZ00B00IE52B00@a-mtaout20.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 20:37:55 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ00A0GIF5I3A0@a-mtaout20.012.net.il>; Mon, 06 Feb 2012 20:37:54 +0200 (IST) In-reply-to: <87r4y74zew.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:56584 Archived-At: > From: =C3=93scar Fuentes > Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.= org > Date: Mon, 06 Feb 2012 18:58:15 +0100 >=20 > >> /* We need this because nt/inc/sys/stat.h defines struct stat th= at is > >> incompatible with the MS run-time libraries. */ > >>=20 > >> That looks like an understatement. Actually, we need our own sta= t > >> function and struct because the `struct stat' that Emacs uses is > >> incompatible with the one defined in MSVCRT, right? > > > > No, you are missing the point of that comment. lib-src/ntlib.c i= s not > > compiled into Emacs, it's compiled into lib-src programs. > > Theoretically, since those programs don't need anything fancy fro= m > > `stat', they could use the stock MSVCRT implementation. But beca= use > > these programs are compiled with -I../nt/inc, the compiler picks = up > > the definition of `struct stat' that is used by Emacs, and becaus= e of > > this incompatibility lib-src programs cannot use the MSVCRT > > implementation of `stat'. >=20 > I think you are saying essentially the same as I do but with very > different words. No, I'm not. > OTOH, you are saying "lib-src/ntlib.c is not compiled into Emacs, i= t's > compiled into lib-src programs." and the key hypotheses made by me = here > is that Emacs uses the `stat' definition on lib-src/ntlib.c. Is tha= t > correct? No. The `stat' Emacs uses is in w32.c. What you see on lib-src/ntlib.c is just a minimal subset of what we have in w32.c. > Symlinks are detected and handled specially on MSVCRT's stat. In > aessence, for symlinks it uses fstat. But fstat probably calls GetFileInformationByHandle under the hood, and we already call that function in w32.c:stat. So maybe the fix is not as ugly and inelegant as you thought. > > We cannot afford to make such a change before the release, no mat= ter > > how far away is it, even if I'd agree to that (which I don't). `= stat' > > is too central to Emacs operation to make such changes at this ti= me. >=20 > Such change would be conceptually straightforward and quite safe. I= t > amounts to using MSVCRT `stat' and translating its `struct stat' to > Emacs' `struct stat'. Instead of defining our own `stat' and `struc= t > stat' we define `emacs_w32_stat' and `struct emacs_w32_stat' and do >=20 > #if windows > #define stat emacs_w32_stat > #endif This doesn't work. I don't remember all the details at the moment, but it's not a coincidence we define `stat' in w32.c, not `sys_stat', as we do with other functions. One immediate problem with this is that we also have our own implementation of `fstat' on w32.c, and the= y must both share the same `struct stat'. It gets really ugly, believe me. Anyway, I don't think we need to call MSVCRT's `fstat' to fix this, see above. > I don't get your mention to inode numbers, UID and GID. The > implementation on ntlib.c simply does >=20 > buf->st_ino =3D 0; >=20 > and I see no references to UID and GID. See above: you are looking at the wrong `stat'. The one that caused all this is on w32.c. > >> BTW, the obvious fix may require some care for not breaking Emac= s > >> support on MS Windows versions prior to XP. We still support Win= dows 9x, > >> don't we? > > > > Yes, we do. In fact, Emacs 24.1 will again work on Windows 9X, a= fter > > it turned out that 23.x (and perhaps also 22.x) didn't. >=20 > So we are reintroducing support for a legacy OS after being de fact= o > removed for several years. Curious. It wasn't a "removal", it was a tricky bug. Anyway, see this discussion: http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00785.html http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00827.html