From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ota, Takaaki" Newsgroups: gmane.emacs.bugs Subject: bug#10733: 24.0.93; w32 file truncation Date: Mon, 6 Feb 2012 12:19:53 -0800 Message-ID: <20120206.121953.215407921.Takaaki.Ota@am.sony.com> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1328559685 29891 80.91.229.3 (6 Feb 2012 20:21:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2012 20:21:25 +0000 (UTC) Cc: ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org To: Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 06 21:21:24 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 1RuV3w-0003Ys-Db for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2012 21:21:20 +0100 Original-Received: from localhost ([::1]:54558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuV3v-0002Mi-1e for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2012 15:21:19 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuV3o-0002MX-Cz for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 15:21:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuV3m-0004Ol-Hr for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 15:21:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuV3m-0004Oh-GF for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 15:21:10 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RuV4b-0007R6-U4 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 15:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Ota, Takaaki" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 20:22:01 +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.132855966528514 (code B ref 10733); Mon, 06 Feb 2012 20:22:01 +0000 Original-Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 20:21:05 +0000 Original-Received: from localhost ([127.0.0.1]:57572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuV3g-0007Pp-6g for submit@debbugs.gnu.org; Mon, 06 Feb 2012 15:21:04 -0500 Original-Received: from am1ehsobe006.messaging.microsoft.com ([213.199.154.209]:27649 helo=AM1EHSOBE001.bigfish.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuV3a-0007PI-KY for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 15:21:02 -0500 Original-Received: from mail32-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Feb 2012 20:20:00 +0000 Original-Received: from mail32-am1 (localhost [127.0.0.1]) by mail32-am1-R.bigfish.com (Postfix) with ESMTP id A4E4340398; Mon, 6 Feb 2012 20:20:00 +0000 (UTC) X-SpamScore: -18 X-BigFish: VPS-18(z21eNzc89bh146fK1432N98dKzz1202hzz8275dhz2fh668h839h) X-Forefront-Antispam-Report: CIP:160.33.98.74; KIP:(null); UIP:(null); IPV:NLI; H:mail7.fw-bc.sony.com; RD:mail7.fw-bc.sony.com; EFVD:NLI Received-SPF: pass (mail32-am1: domain of am.sony.com designates 160.33.98.74 as permitted sender) client-ip=160.33.98.74; envelope-from=Takaaki.Ota@am.sony.com; helo=mail7.fw-bc.sony.com ; -bc.sony.com ; Original-Received: from mail32-am1 (localhost.localdomain [127.0.0.1]) by mail32-am1 (MessageSwitch) id 1328559598818695_16532; Mon, 6 Feb 2012 20:19:58 +0000 (UTC) Original-Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.242]) by mail32-am1.bigfish.com (Postfix) with ESMTP id C345420048; Mon, 6 Feb 2012 20:19:58 +0000 (UTC) Original-Received: from mail7.fw-bc.sony.com (160.33.98.74) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Feb 2012 20:19:56 +0000 Original-Received: from mail2x.bc.in.sel.sony.com (mail3.bc.in.sel.sony.com [43.144.100.56]) by mail7.fw-bc.sony.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id q16KJtmm027657; Mon, 6 Feb 2012 20:19:55 GMT Original-Received: from localhost (fantawin8.am.sony.com [43.191.14.206] (may be forged)) by mail2x.bc.in.sel.sony.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id q16KJrBU027878; Mon, 6 Feb 2012 20:19:54 GMT In-Reply-To: <83sjinbyez.fsf@gnu.org> X-Mailer: Mew-6.3.50 on Emacs-24.0.93.1 (i386-mingw-nt6.1.7601 built on 2012-01-29) X-OriginatorOrg: am.sony.com 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:56585 Archived-At: For your information: (file-attributes "memo") (nil 1 544 513 (20269 7834) (20269 7834) (20269 7834) 0 "-rw-rw-rw-" ni= l (8448 8 . 22758) (62004 . 15649)) (file-attributes "memo.old") (nil 1 544 513 (19686 63524) (20262 20973) (19686 63524) 233153 "-r--r-= -r--" nil (512 5 . 24351) (62004 . 15649)) where "memo" is the NTFS symlink and "memo.old" is a real file. I don't know how the size 0 on symlink side is translated into 64K. -Tak Mon, 6 Feb 2012 10:37:56 -0800: Eli Zaretskii wrote: > > From: =D3scar Fuentes > > Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.= org > > Date: Mon, 06 Feb 2012 18:58:15 +0100 > > = > > >> /* We need this because nt/inc/sys/stat.h defines struct stat th= at is > > >> incompatible with the MS run-time libraries. */ > > >> = > > >> 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'. > > = > > 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. > > = > > 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= > > = > > #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 > > = > > buf->st_ino =3D 0; > > = > > 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. > > = > > 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= > =