From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?=C3=93scar?= Fuentes Newsgroups: gmane.emacs.bugs Subject: bug#10733: 24.0.93; w32 file truncation Date: Mon, 06 Feb 2012 18:58:15 +0100 Message-ID: <87r4y74zew.fsf@wanadoo.es> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1328551345 24785 80.91.229.3 (6 Feb 2012 18:02:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2012 18:02:25 +0000 (UTC) Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 06 19:02:23 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 1RuStS-000855-1x for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2012 19:02:22 +0100 Original-Received: from localhost ([::1]:53033 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuStR-0002wE-Jv for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Feb 2012 13:02:21 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuStK-0002w6-Ti for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:02:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuStH-00037N-2P for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:02:14 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuStG-00037E-T4 for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:02:10 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RuSu5-0004EQ-Id for bug-gnu-emacs@gnu.org; Mon, 06 Feb 2012 13:03:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 18:03: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.132855138116263 (code B ref 10733); Mon, 06 Feb 2012 18:03:01 +0000 Original-Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 18:03:01 +0000 Original-Received: from localhost ([127.0.0.1]:57501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuSu4-0004EC-Dl for submit@debbugs.gnu.org; Mon, 06 Feb 2012 13:03:00 -0500 Original-Received: from impaqm2.telefonica.net ([213.4.138.18]:42476 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuSu0-0004E2-L6 for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 13:02:59 -0500 Original-Received: from IMPmailhost1.adm.correo ([10.20.102.38]) by IMPaqm2.telefonica.net with bizsmtp id WhM51i00F0piX6q3NhyHak; Mon, 06 Feb 2012 18:58:18 +0100 Original-Received: from qcore ([88.11.106.32]) by IMPmailhost1.adm.correo with BIZ IMP id WhyF1i00w0hxhHC1hhyGSt; Mon, 06 Feb 2012 18:58:17 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net In-Reply-To: <83vcnjc1yj.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Feb 2012 19:21:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) 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:56581 Archived-At: Eli Zaretskii writes: >> > I bet it is a bug on the CRT (the stat call that retrieves the file >> > size, to be precise). Maybe it is a MinGW thing. >> >> No, it is an Emacs thing. `stat' is defined in lib-src/ntlib.c, >> overriding the MSVCRT implementation, which accounts for symlinks, while >> Emacs' does not. > > Can you tell the details, please? Specifically, what would it take to > "account for symlinks" in our implementation of `stat'? You did say > symlinks were supposed to be transparent. Transparent for applications, yes. The CRT is not an application. If you replace CRT functions with your own, the transparency goes away. >> Before the definition of `stat' on lib-src/ntlib.c there is this >> comment: >> >> /* We need this because nt/inc/sys/stat.h defines struct stat that is >> incompatible with the MS run-time libraries. */ >> >> That looks like an understatement. Actually, we need our own stat >> 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 is not > compiled into Emacs, it's compiled into lib-src programs. > Theoretically, since those programs don't need anything fancy from > `stat', they could use the stock MSVCRT implementation. But because > these programs are compiled with -I../nt/inc, the compiler picks up > the definition of `struct stat' that is used by Emacs, and because 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. OTOH, you are saying "lib-src/ntlib.c is not compiled into Emacs, it'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 that correct? >> The obvious fix does not seem difficult, although ugly and >> verbose. > > Can you please describe the problem, in addition to what you propose > to be a solution? Symlinks are detected and handled specially on MSVCRT's stat. In aessence, for symlinks it uses fstat. It all amounts to 15 lines of simple code. But that's not directly transposable to Emacs' stat because we need to access and translate the MSVCRT `struct stat' that `fstat' creates to the Emacs' `struct stat'. That final part is the "ugly and verbose" part. >> I'll like to remove the Emacs reimplementation of `stat' > > That is a non-starter. The private implementation of `stat' is needed > to support Posix features, such as meaningful inode numbers, UID and > GID, etc. You won't find anything close to that in MSVCRT. Quite a > few parts in Emacs expect those features. > >> How much time we have until the release? > > We cannot afford to make such a change before the release, no matter > 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 time. Such change would be conceptually straightforward and quite safe. It amounts to using MSVCRT `stat' and translating its `struct stat' to Emacs' `struct stat'. Instead of defining our own `stat' and `struct stat' we define `emacs_w32_stat' and `struct emacs_w32_stat' and do #if windows #define stat emacs_w32_stat #endif so no changes are required outside lib-src/ntlib.c and nt/sys/stat.h. I don't get your mention to inode numbers, UID and GID. The implementation on ntlib.c simply does buf->st_ino = 0; and I see no references to UID and GID. Maybe those are obtained elsewhere. As far as I can see a tranlation from MSVCRT's `struct stat' to Emacs' is possible. >> BTW, the obvious fix may require some care for not breaking Emacs >> support on MS Windows versions prior to XP. We still support Windows 9x, >> don't we? > > Yes, we do. In fact, Emacs 24.1 will again work on Windows 9X, after > 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 facto removed for several years. Curious.