From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: "Ota, Takaaki" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Feb 2012 22:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10733 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 10733@debbugs.gnu.org X-Debbugs-Original-To: Received: via spool by submit@debbugs.gnu.org id=B.13284813079225 (code B ref -1); Sun, 05 Feb 2012 22:36:02 +0000 Received: (at submit) by debbugs.gnu.org; 5 Feb 2012 22:35:07 +0000 Received: from localhost ([127.0.0.1]:55921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuAfq-0002Oj-HV for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:35:07 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56967) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuAfn-0002OE-6g for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:35:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuAew-0003uX-5k for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:34:11 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RECEIVED_FROM_WINDOWS_HOST autolearn=no version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:40152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuAew-0003uT-4H for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:34:10 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuAeu-0008TY-UI for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2012 17:34:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuAes-0003tW-DQ for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2012 17:34:08 -0500 Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:15954 helo=VA3EHSOBE009.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuAes-0003tB-8e for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2012 17:34:06 -0500 Received: from mail157-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Feb 2012 22:34:04 +0000 Received: from mail157-va3 (localhost [127.0.0.1]) by mail157-va3-R.bigfish.com (Postfix) with ESMTP id B3788300380 for ; Sun, 5 Feb 2012 22:34:04 +0000 (UTC) X-SpamScore: -9 X-BigFish: VPS-9(z21eNz936eKzz1202hzzz2fh668h839h944h) 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 (mail157-va3: 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 ; Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3 (MessageSwitch) id 1328481243245735_13019; Sun, 5 Feb 2012 22:34:03 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.241]) by mail157-va3.bigfish.com (Postfix) with ESMTP id 333A1E0046 for ; Sun, 5 Feb 2012 22:34:03 +0000 (UTC) Received: from mail7.fw-bc.sony.com (160.33.98.74) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Feb 2012 22:34:02 +0000 Received: from mail2x.bc.in.sel.sony.com (mail.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 q15MY2dv001734 for ; Sun, 5 Feb 2012 22:34:02 GMT Received: from localhost ([43.142.224.238]) by mail2x.bc.in.sel.sony.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id q15MY1b8020302 for ; Sun, 5 Feb 2012 22:34:01 GMT Date: Sun, 5 Feb 2012 14:34:00 -0800 Message-ID: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> From: "Ota, Takaaki" X-Mailer: Mew-6.3.50 on Emacs-24.0.93.1 (i386-mingw-nt6.1.7601 built on 2012-01-29) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginatorOrg: am.sony.com X-detected-operating-system: by eggs.gnu.org: Windows XP/2000 (RFC1323+, w+, tstamp-) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) When opening a file on an NTFS file system the file opens as if the content is truncated to size of 65375 characters. This happens when the file is an NTFS symbolic link which is made by mklink command of cmd.exe. There is no problem if the target file of the NTFS symbolic link is smaller than this size. -Tak --text follows this line-- This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgement at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file c:/emacs/emacs-24.0.93/etc/DEBUG. In GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601) of 2012-01-29 on TAK-VAIO-Z1290 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --with-gcc (4.5) --cflags -Ic:/d/pub/emacs/include --ldflags -Lc:/d/pub/emacs/lib' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: ESC x f i n d SPC f i SPC m e m o ESC : ( p o i n t ) ESC : r e p o r t SPC C-g ESC x r e p o r SPC e m SPC SPC Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. You can run the command `find-file' with C-x C-f scroll-up-command: End of buffer [21 times] byte-code: End of buffer [21 times] 65375 (#o177537, #xff5f) Quit Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer button faces cus-face files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty emacs) From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Juanma Barranquero Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Feb 2012 23:54: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: To: "Ota, Takaaki" Cc: 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132848599617040 (code B ref 10733); Sun, 05 Feb 2012 23:54:01 +0000 Received: (at 10733) by debbugs.gnu.org; 5 Feb 2012 23:53:16 +0000 Received: from localhost ([127.0.0.1]:55960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuBtT-0004Qn-HD for submit@debbugs.gnu.org; Sun, 05 Feb 2012 18:53:16 -0500 Received: from mail-pz0-f42.google.com ([209.85.210.42]:58395) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuBtQ-0004QZ-Jc for 10733@debbugs.gnu.org; Sun, 05 Feb 2012 18:53:13 -0500 Received: by dang27 with SMTP id g27so5191765dan.29 for <10733@debbugs.gnu.org>; Sun, 05 Feb 2012 15:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dWSLNor5TDLIbgtTVVDVgfjVuxw9BFmeV+AhDK6b3bo=; b=h5DUiKb3ZJIGZ++GLSwcdKe8RDTiK1CbBlByiBTHae9FHfYU6qDCxpjrrivgzVi2tt wLcElDu6wS0ddMIzdAdENK4GWCMbtA2wkmw2yYmSYCz2d2oT09PGp7NJajtnG2OBmGV8 PwpH5hVRuQs+muuO7jdVSECSMmA/8HsGm/F+Y= Received: by 10.68.75.135 with SMTP id c7mr41666424pbw.43.1328485940179; Sun, 05 Feb 2012 15:52:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.37.9 with HTTP; Sun, 5 Feb 2012 15:51:40 -0800 (PST) In-Reply-To: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> References: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> From: Juanma Barranquero Date: Mon, 6 Feb 2012 00:51:40 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > When opening a file on an NTFS file system the file opens as if the > content is truncated to size of 65375 characters. =C2=A0This happens when > the file is an NTFS symbolic link which is made by mklink command of > cmd.exe. =C2=A0There is no problem if the target file of the NTFS symboli= c > link is smaller than this size. Can you please give a step-by-step recipe, starting from "emacs -Q"? Thanks, =C2=A0 =C2=A0 Juanma From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 00:18: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: To: Cc: 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132848744719121 (code B ref 10733); Mon, 06 Feb 2012 00:18:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 00:17:27 +0000 Received: from localhost ([127.0.0.1]:55973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuCGs-0004yL-Bc for submit@debbugs.gnu.org; Sun, 05 Feb 2012 19:17:27 -0500 Received: from am1ehsobe004.messaging.microsoft.com ([213.199.154.207]:30894 helo=AM1EHSOBE006.bigfish.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuCGo-0004y2-M1 for 10733@debbugs.gnu.org; Sun, 05 Feb 2012 19:17:25 -0500 Received: from mail113-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Feb 2012 00:16:29 +0000 Received: from mail113-am1 (localhost [127.0.0.1]) by mail113-am1-R.bigfish.com (Postfix) with ESMTP id 7710C320153; Mon, 6 Feb 2012 00:16:29 +0000 (UTC) X-SpamScore: -19 X-BigFish: VPS-19(z21eNz1432N98dK4015Lzz1202hzz8275bhz2fh668h839h) 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 (mail113-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 ; Received: from mail113-am1 (localhost.localdomain [127.0.0.1]) by mail113-am1 (MessageSwitch) id 1328487387178024_19749; Mon, 6 Feb 2012 00:16:27 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.239]) by mail113-am1.bigfish.com (Postfix) with ESMTP id 2779C200AD; Mon, 6 Feb 2012 00:16:27 +0000 (UTC) Received: from mail7.fw-bc.sony.com (160.33.98.74) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Feb 2012 00:16:26 +0000 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 q160GPiI025367; Mon, 6 Feb 2012 00:16:25 GMT Received: from localhost ([43.142.224.118]) by mail2x.bc.in.sel.sony.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id q160GNsI023903; Mon, 6 Feb 2012 00:16:24 GMT Date: Sun, 5 Feb 2012 16:16:23 -0800 Message-ID: <20120205.161623.484163522.Takaaki.Ota@am.sony.com> From: "Ota, Takaaki" In-Reply-To: References: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> X-Mailer: Mew-6.3.50 on Emacs-24.0.93.1 (i386-mingw-nt6.1.7601 built on 2012-01-29) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: am.sony.com X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Yes, I can do that. 1. Have a text file that has more than 65375 characters. Let's call this text file test.txt. 2. Run cmd.exe and change directory to where test.txt is located. 3. Then execute the next command in the cmd. mklink link.txt test.txt 4. Now run emacs as "emacs -Q link.txt" and do M-> (end-of-buffer). 5. Find that you are not seeing the end of the file but somewhere around 65375 character location and the rest of the file is not visible. -Tak Sun, 5 Feb 2012 15:51:40 -0800: Juanma Barranquero w= rote: > > When opening a file on an NTFS file system the file opens as if the= > > content is truncated to size of 65375 characters. =A0This happens w= hen > > the file is an NTFS symbolic link which is made by mklink command o= f > > cmd.exe. =A0There is no problem if the target file of the NTFS symb= olic > > link is smaller than this size. > = > Can you please give a step-by-step recipe, starting from "emacs -Q"? > = > Thanks, > = > =A0 =A0 Juanma > = From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 00: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: To: Juanma Barranquero Cc: "Ota, Takaaki" , 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132848769919486 (code B ref 10733); Mon, 06 Feb 2012 00:22:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 00:21:39 +0000 Received: from localhost ([127.0.0.1]:55978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuCKx-00054E-Dj for submit@debbugs.gnu.org; Sun, 05 Feb 2012 19:21:39 -0500 Received: from impaqm1.telefonica.net ([213.4.138.17]:17029 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuCKr-00053z-3A for 10733@debbugs.gnu.org; Sun, 05 Feb 2012 19:21:35 -0500 Received: from IMPmailhost3.adm.correo ([10.20.102.124]) by IMPaqm1.telefonica.net with bizsmtp id WQKf1i01a2h2L9m3MQLkig; Mon, 06 Feb 2012 01:20:44 +0100 Received: from qcore ([88.11.106.32]) by IMPmailhost3.adm.correo with BIZ IMP id WQLi1i00H0hxhHC1jQLjmy; Mon, 06 Feb 2012 01:20:44 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> Date: Mon, 06 Feb 2012 01:20:42 +0100 In-Reply-To: (Juanma Barranquero's message of "Mon, 6 Feb 2012 00:51:40 +0100") Message-ID: <87bopc6cdh.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Juanma Barranquero writes: >> When opening a file on an NTFS file system the file opens as if the >> content is truncated to size of 65375 characters. =C2=A0This happens when >> the file is an NTFS symbolic link which is made by mklink command of >> cmd.exe. =C2=A0There is no problem if the target file of the NTFS symbol= ic >> link is smaller than this size. > > Can you please give a step-by-step recipe, starting from "emacs -Q"? I can reproduce the problem on Windows 7 64 bits: * Run a cmd shell as Administrator (mklink is a privileged command). * Navigate to a directory with a text file larger than 64 KB (let's suppose that the file is named foo.txt). * mklink bar.txt foo.txt. * runemacs -Q bar.txt * The file appears truncated in Emacs. Very odd. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 04:08: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: To: "Ota, Takaaki" Cc: lekktu@gmail.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13285012576759 (code B ref 10733); Mon, 06 Feb 2012 04:08:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 04:07:37 +0000 Received: from localhost ([127.0.0.1]:56103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuFrd-0001kw-7J for submit@debbugs.gnu.org; Sun, 05 Feb 2012 23:07:37 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:60521) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuFra-0001kk-U3 for 10733@debbugs.gnu.org; Sun, 05 Feb 2012 23:07:35 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LYY00L00DWDZX00@a-mtaout20.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 06:05:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYY00LRAE1VXO10@a-mtaout20.012.net.il>; Mon, 06 Feb 2012 06:05:56 +0200 (IST) Date: Mon, 06 Feb 2012 06:05:58 +0200 From: Eli Zaretskii In-reply-to: <20120205.161623.484163522.Takaaki.Ota@am.sony.com> X-012-Sender: halo1@inter.net.il Message-id: <83zkcwbo7t.fsf@gnu.org> References: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> <20120205.161623.484163522.Takaaki.Ota@am.sony.com> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > Date: Sun, 5 Feb 2012 16:16:23 -0800 > From: "Ota, Takaaki" > Cc: 10733@debbugs.gnu.org > > Yes, I can do that. > > 1. Have a text file that has more than 65375 characters. Let's call > this text file test.txt. > > 2. Run cmd.exe and change directory to where test.txt is located. > > 3. Then execute the next command in the cmd. > > mklink link.txt test.txt > > 4. Now run emacs as "emacs -Q link.txt" and do M-> (end-of-buffer). > > 5. Find that you are not seeing the end of the file but somewhere > around 65375 character location and the rest of the file is not > visible. Emacs on Windows doesn't support symlinks; they are new with Vista and Windows 7. Someone needs to write the code to support that, before this can be considered a bug (as opposed to a feature request). What you describe seems to indicate that insert-file-contents only reads the first 64KB portion of the file, and then bails out. Running Emacs under debugger and reporting where it bails out of the reading loop might help coming up with some band-aid solution. But full support of symlink requires specific support code, that just isn't there at this time. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 05:27: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: To: Eli Zaretskii Cc: lekktu@gmail.com, "Ota, Takaaki" , 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132850599013516 (code B ref 10733); Mon, 06 Feb 2012 05:27:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 05:26:30 +0000 Received: from localhost ([127.0.0.1]:56146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuH5x-0003Vx-Kg for submit@debbugs.gnu.org; Mon, 06 Feb 2012 00:26:30 -0500 Received: from impaqm5.telefonica.net ([213.4.138.21]:45356 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuH5s-0003Vk-Rw for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 00:26:27 -0500 Received: from IMPmailhost4.adm.correo ([10.20.102.125]) by IMPaqm5.telefonica.net with bizsmtp id WVGm1i0192iL0W23RVRaof; Mon, 06 Feb 2012 06:25:34 +0100 Received: from qcore ([88.11.106.32]) by IMPmailhost4.adm.correo with BIZ IMP id WVRY1i00E0hxhHC1kVRZKr; Mon, 06 Feb 2012 06:25:34 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> <20120205.161623.484163522.Takaaki.Ota@am.sony.com> <83zkcwbo7t.fsf@gnu.org> Date: Mon, 06 Feb 2012 06:25:32 +0100 In-Reply-To: <83zkcwbo7t.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Feb 2012 06:05:58 +0200") Message-ID: <874nv45y9f.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: [snip] > Emacs on Windows doesn't support symlinks; they are new with Vista and > Windows 7. Someone needs to write the code to support that, before > this can be considered a bug (as opposed to a feature request). > > What you describe seems to indicate that insert-file-contents only > reads the first 64KB portion of the file, and then bails out. Running > Emacs under debugger and reporting where it bails out of the reading > loop might help coming up with some band-aid solution. But full > support of symlink requires specific support code, that just isn't > there at this time. NTFS symlinks are transparent to applications. Emacs doesn't need to know that it is accessing a symlink to correctly read and save the file. 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. It would be interesting to hear reports from people using an Emacs compiled with a modern version of Visual Studio, or even know if people using the most recent MinGW CRT release can duplicate the problem. This is a very serious bug (potential data loss). I'll put this on my TODO list and hopefully run a debug session on a Windows 7 machine next week. Meanwhile, if anyone can provide the info mentioned on the previous paragraph, it would be helpful. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 16:19: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: To: 10733@debbugs.gnu.org Cc: lekktu@gmail.com, Eli Zaretskii , "Ota, Takaaki" Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13285450926263 (code B ref 10733); Mon, 06 Feb 2012 16:19:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 16:18:12 +0000 Received: from localhost ([127.0.0.1]:57382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuRGa-0001cs-7G for submit@debbugs.gnu.org; Mon, 06 Feb 2012 11:18:12 -0500 Received: from impaqm1.telefonica.net ([213.4.138.17]:49189 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuRGT-0001cJ-Tk for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 11:18:06 -0500 Received: from IMPmailhost3.adm.correo ([10.20.102.124]) by IMPaqm1.telefonica.net with bizsmtp id WgGq1i01T2h2L9m3MgGuna; Mon, 06 Feb 2012 17:16:54 +0100 Received: from qcore ([88.11.106.32]) by IMPmailhost3.adm.correo with BIZ IMP id WgGs1i01P0hxhHC1jgGtpi; Mon, 06 Feb 2012 17:16:54 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> Date: Mon, 06 Feb 2012 17:16:52 +0100 In-Reply-To: <874nv45y9f.fsf@wanadoo.es> ("=?UTF-8?Q?=C3=93scar?= Fuentes"'s message of "Mon, 06 Feb 2012 06:25:32 +0100") Message-ID: <87zkcw3pjf.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) =C3=93scar Fuentes 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. 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? The obvious fix does not seem difficult, although ugly and verbose. OTOH, I'll like to remove the Emacs reimplementation of `stat', but that looks more cumbersome. How much time we have until the release? 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? From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 16:57: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: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13285474119746 (code B ref 10733); Mon, 06 Feb 2012 16:57:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 16:56:51 +0000 Received: from localhost ([127.0.0.1]:57391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuRs1-0002X8-Vf for submit@debbugs.gnu.org; Mon, 06 Feb 2012 11:56:51 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:38483) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuRrz-0002Wu-3Z for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 11:56:48 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LYZ00I00DM3A700@a-mtaout23.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 18:55:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ00IXLDOY7U50@a-mtaout23.012.net.il>; Mon, 06 Feb 2012 18:55:47 +0200 (IST) Date: Mon, 06 Feb 2012 18:55:49 +0200 From: Eli Zaretskii In-reply-to: <874nv45y9f.fsf@wanadoo.es> Message-id: <83y5sfc356.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il 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> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: =D3scar Fuentes > Cc: "Ota\, Takaaki" , lekktu@gmail.com, = 10733@debbugs.gnu.org > Date: Mon, 06 Feb 2012 06:25:32 +0100 >=20 > NTFS symlinks are transparent to applications. Well, evidently, they aren't. > Emacs doesn't need to know that it is accessing a symlink to > correctly read and save the file. Evidently, it does. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 17:23: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: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132854896812198 (code B ref 10733); Mon, 06 Feb 2012 17:23:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 17:22:48 +0000 Received: from localhost ([127.0.0.1]:57427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuSHA-0003Ah-3N for submit@debbugs.gnu.org; Mon, 06 Feb 2012 12:22:48 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:54303) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuSH5-0003AQ-TR for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 12:22:45 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LYZ00A00DVC3B00@a-mtaout20.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 19:21:22 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ009RAEVLKRB0@a-mtaout20.012.net.il>; Mon, 06 Feb 2012 19:21:22 +0200 (IST) Date: Mon, 06 Feb 2012 19:21:24 +0200 From: Eli Zaretskii In-reply-to: <87zkcw3pjf.fsf@wanadoo.es> Message-id: <83vcnjc1yj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il 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> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: =C3=93scar Fuentes > Cc: Eli Zaretskii , lekktu@gmail.com, "Ota\, Takaak= i" > Date: Mon, 06 Feb 2012 17:16:52 +0100 >=20 > =C3=93scar Fuentes writes: >=20 > > I bet it is a bug on the CRT (the stat call that retrieves the fi= le > > size, to be precise). Maybe it is a MinGW thing. >=20 > 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 t= o "account for symlinks" in our implementation of `stat'? You did say symlinks were supposed to be transparent. > Before the definition of `stat' on lib-src/ntlib.c there is this > comment: >=20 > /* We need this because nt/inc/sys/stat.h defines struct stat that = is > incompatible with the MS run-time libraries. */ >=20 > 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 no= t 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'. > 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? > I'll like to remove the Emacs reimplementation of `stat' That is a non-starter. The private implementation of `stat' is neede= d 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. > BTW, the obvious fix may require some care for not breaking Emacs > support on MS Windows versions prior to XP. We still support Window= s 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. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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: To: Eli Zaretskii Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132855138116263 (code B ref 10733); Mon, 06 Feb 2012 18:03:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 18:03:01 +0000 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 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 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 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 From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> Date: Mon, 06 Feb 2012 18:58:15 +0100 In-Reply-To: <83vcnjc1yj.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Feb 2012 19:21:24 +0200") Message-ID: <87r4y74zew.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132855354019440 (code B ref 10733); Mon, 06 Feb 2012 18:39:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 18:39:00 +0000 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 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 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) 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) Date: Mon, 06 Feb 2012 20:37:56 +0200 From: Eli Zaretskii In-reply-to: <87r4y74zew.fsf@wanadoo.es> Message-id: <83sjinbyez.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il 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> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > 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 From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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: To: Cc: ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132855966528514 (code B ref 10733); Mon, 06 Feb 2012 20:22:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 20:21:05 +0000 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 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 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 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 ; 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) 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) 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 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 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 Date: Mon, 6 Feb 2012 12:19:53 -0800 Message-ID: <20120206.121953.215407921.Takaaki.Ota@am.sony.com> From: "Ota, Takaaki" In-Reply-To: <83sjinbyez.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <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) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: am.sony.com X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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= > = From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 20:25: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: To: "Ota, Takaaki" Cc: ofv@wanadoo.es, lekktu@gmail.com, eliz@gnu.org, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132855987928823 (code B ref 10733); Mon, 06 Feb 2012 20:25:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 20:24:39 +0000 Received: from localhost ([127.0.0.1]:57578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuV79-0007Uq-Cv for submit@debbugs.gnu.org; Mon, 06 Feb 2012 15:24:39 -0500 Received: from mail-lpp01m010-f44.google.com ([209.85.215.44]:43142) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuV78-0007Ue-3L for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 15:24:38 -0500 Received: by lahl5 with SMTP id l5so3238553lah.3 for <10733@debbugs.gnu.org>; Mon, 06 Feb 2012 12:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yKsL6z4l3z2XKfXoa8ybv7QdhCJ+pLGRZeZ5/v1j2Z0=; b=ZJGqlFZIiadCh6FnCIGRIRp6U+B4RGNl0W3U7+mWDIAkFDWnGdezc+SmxCBhZqL7bi gui+pZo4hBZtjWdZvMI6gvPuaRe9VH/iX+4vrnkogcQIxZ5WEMKakQAT6UExoWfaAK88 mQLNZtVwSbcZxOc6fPz08M3/JakBC5uzhXwUk= Received: by 10.152.148.9 with SMTP id to9mr3272963lab.1.1328559820219; Mon, 06 Feb 2012 12:23:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.12.6 with HTTP; Mon, 6 Feb 2012 12:23:20 -0800 (PST) In-Reply-To: <20120206.121953.215407921.Takaaki.Ota@am.sony.com> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> From: Lennart Borgman Date: Mon, 6 Feb 2012 21:23:20 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) To me it seems quite scary that Emacs has its own implementation of such low level functions. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Lars Ingebrigtsen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 20:26: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: To: "Ota\, Takaaki" Cc: ofv@wanadoo.es, lekktu@gmail.com, eliz@gnu.org, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132855991828902 (code B ref 10733); Mon, 06 Feb 2012 20:26:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 20:25:18 +0000 Received: from localhost ([127.0.0.1]:57582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuV7i-0007W4-KV for submit@debbugs.gnu.org; Mon, 06 Feb 2012 15:25:18 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:56249) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuV7d-0007Vq-1f for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 15:25:13 -0500 Received: from 93-41-188-50.ip82.fastwebnet.it ([93.41.188.50] helo=rusty) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1RuV6c-0007SL-Sd; Mon, 06 Feb 2012 21:24:07 +0100 From: Lars Ingebrigtsen References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> Date: Mon, 06 Feb 2012 21:24:04 +0100 In-Reply-To: <20120206.121953.215407921.Takaaki.Ota@am.sony.com> (Takaaki Ota's message of "Mon, 6 Feb 2012 12:19:53 -0800") Message-ID: <87fwend82j.fsf@gnus.org> User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1RuV6c-0007SL-Sd X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1329164647.31507@AJBXTtid6ZrVy9/awwUrzg X-Spam-Status: No X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) "Ota, Takaaki" writes: > 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. If Emacs doesn't know the size of the file (i.e., the fs says that the file is 0 bytes long), then Emacs will only read the first 64K of the file. This was discussed in the bug report about how /proc files are truncated by Emacs. The fix proposed there (i.e., "read until you get to eof") would probably fix this, too. -- (domestic pets only, the antidote for overdose, milk.) http://lars.ingebrigtsen.no * Sent from my Rome From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 21:11: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: To: "Ota, Takaaki" Cc: ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.1328562618525 (code B ref 10733); Mon, 06 Feb 2012 21:11:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 21:10:18 +0000 Received: from localhost ([127.0.0.1]:57658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuVpK-00008P-1i for submit@debbugs.gnu.org; Mon, 06 Feb 2012 16:10:18 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:63015) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuVpH-00008D-GW for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 16:10:17 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LYZ00I00PD0UL00@a-mtaout23.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 23:08:04 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ00IAUPDET630@a-mtaout23.012.net.il>; Mon, 06 Feb 2012 23:08:04 +0200 (IST) Date: Mon, 06 Feb 2012 23:08:05 +0200 From: Eli Zaretskii In-reply-to: <20120206.121953.215407921.Takaaki.Ota@am.sony.com> X-012-Sender: halo1@inter.net.il Message-id: <83r4y7brgq.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > Date: Mon, 6 Feb 2012 12:19:53 -0800 > CC: , , <10733@debbugs.gnu.org> > From: "Ota, Takaaki" > > For your information: > > (file-attributes "memo") > (nil 1 544 513 (20269 7834) (20269 7834) (20269 7834) 0 "-rw-rw-rw-" nil (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. insert-file-contents reads files in 64KB chunks. So it reads only one chunk. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 21:11: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: To: Lars Ingebrigtsen Cc: ofv@wanadoo.es, lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.1328562653575 (code B ref 10733); Mon, 06 Feb 2012 21:11:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 21:10:53 +0000 Received: from localhost ([127.0.0.1]:57661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuVpp-00009B-EF for submit@debbugs.gnu.org; Mon, 06 Feb 2012 16:10:52 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:53442) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuVpk-00008s-4a for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 16:10:48 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LYZ00C00PCFBH00@a-mtaout20.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 23:09:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ00CL5PG65T40@a-mtaout20.012.net.il>; Mon, 06 Feb 2012 23:09:45 +0200 (IST) Date: Mon, 06 Feb 2012 23:09:46 +0200 From: Eli Zaretskii In-reply-to: <87fwend82j.fsf@gnus.org> X-012-Sender: halo1@inter.net.il Message-id: <83pqdrbrdx.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> <87fwend82j.fsf@gnus.org> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: Lars Ingebrigtsen > Cc: , ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org > Date: Mon, 06 Feb 2012 21:24:04 +0100 > > "Ota, Takaaki" writes: > > > 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. > > If Emacs doesn't know the size of the file (i.e., the fs says that the > file is 0 bytes long), then Emacs will only read the first 64K of the > file. This was discussed in the bug report about how /proc files are > truncated by Emacs. > > The fix proposed there (i.e., "read until you get to eof") would > probably fix this, too. That's a band-aid at best. If Emacs doesn't know the size of the file that is the target of the symlink and its other attributes, other places will break. What is needed is to resolve the link, i.e. do the equivalent of `lstat'. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 21:13: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: To: Lennart Borgman Cc: ofv@wanadoo.es, lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.1328562766762 (code B ref 10733); Mon, 06 Feb 2012 21:13:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 21:12:46 +0000 Received: from localhost ([127.0.0.1]:57666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuVri-0000CF-9c for submit@debbugs.gnu.org; Mon, 06 Feb 2012 16:12:46 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:53991) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuVrf-0000Bz-Vy for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 16:12:44 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LYZ00C00PIQCB00@a-mtaout20.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 23:11:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ00BLMPJKMZF0@a-mtaout20.012.net.il>; Mon, 06 Feb 2012 23:11:45 +0200 (IST) Date: Mon, 06 Feb 2012 23:11:47 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83obtbbrak.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: Lennart Borgman > Date: Mon, 6 Feb 2012 21:23:20 +0100 > Cc: eliz@gnu.org, ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org > > To me it seems quite scary that Emacs has its own implementation of > such low level functions. Don't worry: `stat' is a low-level function on Posix platforms, but not on Windows. w32.c is full of such "low-level" functions, reimplemented to be more Posix like, because MSVCRT does a very poor job in that regard, and Emacs expects Posix-compliance in quite a few places. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 21: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: To: Eli Zaretskii Cc: ofv@wanadoo.es, lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13285633131567 (code B ref 10733); Mon, 06 Feb 2012 21:22:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 21:21:53 +0000 Received: from localhost ([127.0.0.1]:57680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuW0U-0000PC-ML for submit@debbugs.gnu.org; Mon, 06 Feb 2012 16:21:52 -0500 Received: from mail-lpp01m020-f172.google.com ([209.85.217.172]:43005) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuW0T-0000P1-2h for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 16:21:49 -0500 Received: by lbbgk8 with SMTP id gk8so1192199lbb.3 for <10733@debbugs.gnu.org>; Mon, 06 Feb 2012 13:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i4csxJx4feuhfvVZO7TaZmxI6hvsV8XqtbRpdM4b4bI=; b=rMG6vYc8/8ImbrCszN+n5yPTRuZh6YLUcWsr0q+rlTQ1qwpu7pIUOVNHkgQaR2+dwE BUwBQ2B21btWdbYW+6ZTlnqN71ZcoqICIm1ohqE8SIamgbXLFMLQVupDoNQ4G5VmPNbM z89uEjAHj2qlAesMnzgOqdgPoXFJa+JBM6J7M= Received: by 10.112.102.161 with SMTP id fp1mr5241837lbb.71.1328563251146; Mon, 06 Feb 2012 13:20:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.12.6 with HTTP; Mon, 6 Feb 2012 13:20:31 -0800 (PST) In-Reply-To: <83obtbbrak.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> <83obtbbrak.fsf@gnu.org> From: Lennart Borgman Date: Mon, 6 Feb 2012 22:20:31 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On Mon, Feb 6, 2012 at 22:11, Eli Zaretskii wrote: >> From: Lennart Borgman >> Date: Mon, 6 Feb 2012 21:23:20 +0100 >> Cc: eliz@gnu.org, ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org >> >> To me it seems quite scary that Emacs has its own implementation of >> such low level functions. > > Don't worry: `stat' is a low-level function on Posix platforms, but > not on Windows. That is not what worries me. This is reimplementation is surely necessary. What worries me is the bypassing of MSVCRT. I think that perhaps it is better to reimplement on top of that. But that might be just me. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 21:33: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: To: Lennart Borgman Cc: ofv@wanadoo.es, lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13285639632634 (code B ref 10733); Mon, 06 Feb 2012 21:33:02 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 21:32:43 +0000 Received: from localhost ([127.0.0.1]:57705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuWB0-0000gR-JL for submit@debbugs.gnu.org; Mon, 06 Feb 2012 16:32:42 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:46123) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuWAx-0000gE-UX for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 16:32:40 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LYZ00100QE1IG00@a-mtaout21.012.net.il> for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 23:31:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LYZ001UHQFWFT50@a-mtaout21.012.net.il>; Mon, 06 Feb 2012 23:31:10 +0200 (IST) Date: Mon, 06 Feb 2012 23:31:12 +0200 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83liofbqe7.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> <83obtbbrak.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: Lennart Borgman > Date: Mon, 6 Feb 2012 22:20:31 +0100 > Cc: Takaaki.Ota@am.sony.com, ofv@wanadoo.es, lekktu@gmail.com, > 10733@debbugs.gnu.org > > What worries me is the bypassing of MSVCRT. Why? What do you think `stat' in MSVCRT does? (You can find the sources on the Internet.) It calls some of the same Win32 APIs, and then fills `struct stat'. There''s nothing magic about that, and nothing to be afraid of. > I think that perhaps it is better to reimplement on top of that. You can't. To get the missing information you must go to lower-level APIs. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Feb 2012 21:38: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: To: Eli Zaretskii Cc: ofv@wanadoo.es, lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13285642253038 (code B ref 10733); Mon, 06 Feb 2012 21:38:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 21:37:05 +0000 Received: from localhost ([127.0.0.1]:57713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuWFF-0000mw-2o for submit@debbugs.gnu.org; Mon, 06 Feb 2012 16:37:05 -0500 Received: from mail-lpp01m020-f172.google.com ([209.85.217.172]:33702) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuWFC-0000mT-KS for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 16:37:03 -0500 Received: by lbbgk8 with SMTP id gk8so1197911lbb.3 for <10733@debbugs.gnu.org>; Mon, 06 Feb 2012 13:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Gc+DWUx8ljWkaVH4KTFvuFUD1YyWq83T0oCzYtKwH7w=; b=FN5jPallABdh861gbhzvBWvvexitVVg/KLAuhNVLvl1I+K2wMYlH39guykvoE1QcxL sVCUeQW0bN5oeGMlg5EMNm7eY/j/RZBWPYYFnEfu72gI13LuzVSmisQ3xFOOUl0BQ/cd iyZvSPBqpkOhvqLDY7l25pEf1mr0v6Sy/WYSQ= Received: by 10.112.40.101 with SMTP id w5mr5288962lbk.97.1328564164641; Mon, 06 Feb 2012 13:36:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.12.6 with HTTP; Mon, 6 Feb 2012 13:35:44 -0800 (PST) In-Reply-To: <83liofbqe7.fsf@gnu.org> References: <83vcnjc1yj.fsf@gnu.org> <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <20120206.121953.215407921.Takaaki.Ota@am.sony.com> <83obtbbrak.fsf@gnu.org> <83liofbqe7.fsf@gnu.org> From: Lennart Borgman Date: Mon, 6 Feb 2012 22:35:44 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On Mon, Feb 6, 2012 at 22:31, Eli Zaretskii wrote: >> From: Lennart Borgman >> Date: Mon, 6 Feb 2012 22:20:31 +0100 >> Cc: Takaaki.Ota@am.sony.com, ofv@wanadoo.es, lekktu@gmail.com, >> =C2=A0 =C2=A0 =C2=A0 10733@debbugs.gnu.org >> >> What worries me is the bypassing of MSVCRT. > > Why? =C2=A0What do you think `stat' in MSVCRT does? =C2=A0(You can find t= he > sources on the Internet.) =C2=A0It calls some of the same Win32 APIs, and > then fills `struct stat'. =C2=A0There''s nothing magic about that, and > nothing to be afraid of. Ok, I see. But what seems to have happened now is that changes in these calls that are implemented in MSVCRT are not mirrored in the Emacs reimplementation. (And we are aware that it is a bit serious.) >> I think that perhaps it is better to reimplement on top of that. > > You can't. =C2=A0To get the missing information you must go to lower-leve= l > APIs. Do you say that it would slow down the Emacs implementation to get this information with new calls (beside those potentially going through MSVCRT)? Then I agree. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 23:30: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: To: Eli Zaretskii Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132857094618906 (code B ref 10733); Mon, 06 Feb 2012 23:30:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 23:29:06 +0000 Received: from localhost ([127.0.0.1]:57768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuXze-0004ut-1S for submit@debbugs.gnu.org; Mon, 06 Feb 2012 18:29:06 -0500 Received: from impaqm4.telefonica.net ([213.4.138.20]:4335 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuXza-0004uQ-3a for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 18:29:05 -0500 Received: from IMPmailhost4.adm.correo ([10.20.102.125]) by IMPaqm4.telefonica.net with bizsmtp id WnDK1i00o2iL0W23QnT9ZS; Tue, 07 Feb 2012 00:27:09 +0100 Received: from qcore ([88.11.106.32]) by IMPmailhost4.adm.correo with BIZ IMP id WnT71i00K0hxhHC1knT8LJ; Tue, 07 Feb 2012 00:27:09 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> <83sjinbyez.fsf@gnu.org> Date: Tue, 07 Feb 2012 00:27:07 +0100 In-Reply-To: <83sjinbyez.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Feb 2012 20:37:56 +0200") Message-ID: <87fwen4k6s.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: [snip] > 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. That's important. Thanks. >> 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. Yup. This patch fixes the problem: diff --git a/src/w32.c b/src/w32.c index f610a36..035e1f2 100644 --- a/src/w32.c +++ b/src/w32.c @@ -3444,6 +3444,29 @@ stat (const char * path, struct stat * buf) } } + buf->st_size = 0; + + if ((wfd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) && + (wfd.dwReserved0 == IO_REPARSE_TAG_SYMLINK)) + { + HANDLE fh; + BY_HANDLE_FILE_INFORMATION info; + + if ((fh = CreateFile (name, 0, 0, NULL, OPEN_EXISTING, + FILE_FLAG_BACKUP_SEMANTICS, NULL)) + && GetFileInformationByHandle (fh, &info)) + { + buf->st_size = info.nFileSizeHigh; + buf->st_size <<= 32; + buf->st_size += info.nFileSizeLow; + } + else + { + errno = ENOENT; + return -1; + } + } + if (!(NILP (Vw32_get_true_file_attributes) || (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow_fs (name))) /* No access rights required to get info. */ @@ -3532,9 +3555,12 @@ stat (const char * path, struct stat * buf) buf->st_dev = volume_info.serialnum; buf->st_rdev = volume_info.serialnum; - buf->st_size = wfd.nFileSizeHigh; - buf->st_size <<= 32; - buf->st_size += wfd.nFileSizeLow; + if (! buf->st_size) + { + buf->st_size = wfd.nFileSizeHigh; + buf->st_size <<= 32; + buf->st_size += wfd.nFileSizeLow; + } /* Convert timestamps to Unix format. */ buf->st_mtime = convert_time (wfd.ftLastWriteTime); Maybe it can be integrated in the if (!(NILP(Vw32_get_true_file_attributes) ... hence reusing the calls to CreateFile and GetFileInformationByHandle and shortening the patch, but as I don't know what Vw32_get_true_file_attributes does, preferread to follow the safe way. However, we still have another implementation on ntlib.c. And the fix is just for the size. Don't know if there are other attributes suffer from the same problem. Possibly the right thing is to do what MSVCRT does: if is-symlink? use fstat fi From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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 23:45: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: To: Cc: lekktu@gmail.com, eliz@gnu.org, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132857187520396 (code B ref 10733); Mon, 06 Feb 2012 23:45:01 +0000 Received: (at 10733) by debbugs.gnu.org; 6 Feb 2012 23:44:35 +0000 Received: from localhost ([127.0.0.1]:57784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuYEc-0005Iv-GA for submit@debbugs.gnu.org; Mon, 06 Feb 2012 18:44:34 -0500 Received: from am1ehsobe003.messaging.microsoft.com ([213.199.154.206]:8745 helo=AM1EHSOBE002.bigfish.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuYEY-0005Ie-V9 for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 18:44:32 -0500 Received: from mail118-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Feb 2012 23:43:32 +0000 Received: from mail118-am1 (localhost [127.0.0.1]) by mail118-am1-R.bigfish.com (Postfix) with ESMTP id 1E4A21605DB; Mon, 6 Feb 2012 23:43:32 +0000 (UTC) X-SpamScore: -15 X-BigFish: VPS-15(z21eNzc89bh1432N98dKzz1202hzz8275dhz2fh668h839h) 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 (mail118-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 ; Received: from mail118-am1 (localhost.localdomain [127.0.0.1]) by mail118-am1 (MessageSwitch) id 1328571809812433_15809; Mon, 6 Feb 2012 23:43:29 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.247]) by mail118-am1.bigfish.com (Postfix) with ESMTP id B77BEE0045; Mon, 6 Feb 2012 23:43:29 +0000 (UTC) Received: from mail7.fw-bc.sony.com (160.33.98.74) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 Feb 2012 23:43:29 +0000 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 q16NhShC015770; Mon, 6 Feb 2012 23:43:28 GMT 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 q16NhQp1032175; Mon, 6 Feb 2012 23:43:27 GMT Date: Mon, 6 Feb 2012 15:43:27 -0800 Message-ID: <20120206.154327.522668003.Takaaki.Ota@am.sony.com> From: "Ota, Takaaki" In-Reply-To: <87fwen4k6s.fsf@wanadoo.es> References: <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <87fwen4k6s.fsf@wanadoo.es> X-Mailer: Mew-6.3.50 on Emacs-24.0.93.1 (i386-mingw-nt6.1.7601 built on 2012-01-29) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: am.sony.com X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Don't you need to dispose fh properly? -Tak Mon, 6 Feb 2012 15:27:07 -0800: =D3scar Fuentes wrote:= > Eli Zaretskii writes: > = > [snip] > = > > 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. > = > That's important. Thanks. > = > >> 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. > = > Yup. This patch fixes the problem: > = > diff --git a/src/w32.c b/src/w32.c > index f610a36..035e1f2 100644 > --- a/src/w32.c > +++ b/src/w32.c > @@ -3444,6 +3444,29 @@ stat (const char * path, struct stat * buf) > } > } > = > + buf->st_size =3D 0; > + > + if ((wfd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) && > + (wfd.dwReserved0 =3D=3D IO_REPARSE_TAG_SYMLINK)) > + { > + HANDLE fh; > + BY_HANDLE_FILE_INFORMATION info; > + > + if ((fh =3D CreateFile (name, 0, 0, NULL, OPEN_EXISTING, > + FILE_FLAG_BACKUP_SEMANTICS, NULL)) > + && GetFileInformationByHandle (fh, &info)) > + { > + buf->st_size =3D info.nFileSizeHigh; > + buf->st_size <<=3D 32; > + buf->st_size +=3D info.nFileSizeLow; > + } > + else > + { > + errno =3D ENOENT; > + return -1; > + } > + } > + > if (!(NILP (Vw32_get_true_file_attributes) > || (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow_fs (name)= )) > /* No access rights required to get info. */ > @@ -3532,9 +3555,12 @@ stat (const char * path, struct stat * buf) > buf->st_dev =3D volume_info.serialnum; > buf->st_rdev =3D volume_info.serialnum; > = > - buf->st_size =3D wfd.nFileSizeHigh; > - buf->st_size <<=3D 32; > - buf->st_size +=3D wfd.nFileSizeLow; > + if (! buf->st_size) > + { > + buf->st_size =3D wfd.nFileSizeHigh; > + buf->st_size <<=3D 32; > + buf->st_size +=3D wfd.nFileSizeLow; > + } > = > /* Convert timestamps to Unix format. */ > buf->st_mtime =3D convert_time (wfd.ftLastWriteTime); > = > = > Maybe it can be integrated in the > = > if (!(NILP(Vw32_get_true_file_attributes) ... > = > hence reusing the calls to CreateFile and GetFileInformationByHandle = and > shortening the patch, but as I don't know what > Vw32_get_true_file_attributes does, preferread to follow the safe way= .= > = > However, we still have another implementation on ntlib.c. > = > And the fix is just for the size. Don't know if there are other > attributes suffer from the same problem. Possibly the right thing is = to > do what MSVCRT does: > = > if is-symlink? > use fstat > fi > = From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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: Tue, 07 Feb 2012 00:10: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: To: "Ota\, Takaaki" Cc: ofv@wanadoo.es, lekktu@gmail.com, eliz@gnu.org, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132857336425630 (code B ref 10733); Tue, 07 Feb 2012 00:10:02 +0000 Received: (at 10733) by debbugs.gnu.org; 7 Feb 2012 00:09:24 +0000 Received: from localhost ([127.0.0.1]:57798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuYce-0006fL-7Q for submit@debbugs.gnu.org; Mon, 06 Feb 2012 19:09:24 -0500 Received: from impaqm2.telefonica.net ([213.4.138.18]:38699 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuYca-0006fA-43 for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 19:09:22 -0500 Received: from IMPmailhost6.adm.correo ([10.20.102.127]) by IMPaqm2.telefonica.net with bizsmtp id Wn8R1i00A2kvMAa3No7rEQ; Tue, 07 Feb 2012 01:07:51 +0100 Received: from qcore ([88.11.106.32]) by IMPmailhost6.adm.correo with BIZ IMP id Wo7p1i00D0hxhHC1mo7qG5; Tue, 07 Feb 2012 01:07:51 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes References: <87r4y74zew.fsf@wanadoo.es> <83sjinbyez.fsf@gnu.org> <87fwen4k6s.fsf@wanadoo.es> <20120206.154327.522668003.Takaaki.Ota@am.sony.com> Date: Tue, 07 Feb 2012 01:07:48 +0100 In-Reply-To: <20120206.154327.522668003.Takaaki.Ota@am.sony.com> (Takaaki Ota's message of "Mon, 6 Feb 2012 15:43:27 -0800") Message-ID: <87bopb4iaz.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) "Ota, Takaaki" writes: > Don't you need to dispose fh properly? Yes. And check that it works for directories too. The patch is not intended as a definitive fix, but as a data point on the discussion. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Feb 2012 04:04: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: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132858743020371 (code B ref 10733); Tue, 07 Feb 2012 04:04:01 +0000 Received: (at 10733) by debbugs.gnu.org; 7 Feb 2012 04:03:50 +0000 Received: from localhost ([127.0.0.1]:57955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RucHV-0005IU-NQ for submit@debbugs.gnu.org; Mon, 06 Feb 2012 23:03:49 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:56066) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RucHT-0005Hy-I4 for 10733@debbugs.gnu.org; Mon, 06 Feb 2012 23:03:48 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LZ0009008F9Z200@a-mtaout22.012.net.il> for 10733@debbugs.gnu.org; Tue, 07 Feb 2012 06:02:47 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LZ0009F18KMHGB0@a-mtaout22.012.net.il>; Tue, 07 Feb 2012 06:02:47 +0200 (IST) Date: Tue, 07 Feb 2012 06:02:49 +0200 From: Eli Zaretskii In-reply-to: <87fwen4k6s.fsf@wanadoo.es> Message-id: <83ipjjb89i.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il 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> <83sjinbyez.fsf@gnu.org> <87fwen4k6s.fsf@wanadoo.es> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: =D3scar Fuentes > Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.= org > Date: Tue, 07 Feb 2012 00:27:07 +0100 >=20 > >> Symlinks are detected and handled specially on MSVCRT's stat. In > >> aessence, for symlinks it uses fstat. > > > > But fstat probably calls GetFileInformationByHandle under the hoo= d, > > and we already call that function in w32.c:stat. So maybe the fi= x is > > not as ugly and inelegant as you thought. >=20 > Yup. This patch fixes the problem: Thanks. > Maybe it can be integrated in the >=20 > if (!(NILP(Vw32_get_true_file_attributes) ... >=20 > hence reusing the calls to CreateFile and GetFileInformationByHandl= e and > shortening the patch, but as I don't know what > Vw32_get_true_file_attributes does, preferread to follow the safe w= ay. You did right: w32-get-true-file-attributes can be set by the user to nil, if she wants her file ops faster. > And the fix is just for the size. Don't know if there are other > attributes suffer from the same problem. Possibly the right thing i= s to > do what MSVCRT does: >=20 > if is-symlink? > use fstat > fi Since fstat is also reimplemented, I'd rather do what it does inline. For that, we need to know which other attributes are reported different. Or maybe just test for the reparse point up front and do all the work for the target instead. From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation 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: Tue, 07 Feb 2012 05:24: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: To: Eli Zaretskii Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.132859224227523 (code B ref 10733); Tue, 07 Feb 2012 05:24:02 +0000 Received: (at 10733) by debbugs.gnu.org; 7 Feb 2012 05:24:02 +0000 Received: from localhost ([127.0.0.1]:58041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RudX7-00079n-1v for submit@debbugs.gnu.org; Tue, 07 Feb 2012 00:24:01 -0500 Received: from impaqm1.telefonica.net ([213.4.138.17]:2417 helo=telefonica.net) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RudX2-00079X-5A for 10733@debbugs.gnu.org; Tue, 07 Feb 2012 00:23:59 -0500 Received: from IMPmailhost2.adm.correo ([10.20.102.39]) by IMPaqm1.telefonica.net with bizsmtp id WtMw1i00n0r0BT63MtNEWL; Tue, 07 Feb 2012 06:22:14 +0100 Received: from qcore ([88.11.106.32]) by IMPmailhost2.adm.correo with BIZ IMP id WtND1i0010hxhHC1itNDNH; Tue, 07 Feb 2012 06:22:14 +0100 X-Brightmail-Tracker: AAAAAA== X-original-sender: 981711563@telefonica.net From: =?UTF-8?Q?=C3=93scar?= Fuentes 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> <83sjinbyez.fsf@gnu.org> <87fwen4k6s.fsf@wanadoo.es> <83ipjjb89i.fsf@gnu.org> Date: Tue, 07 Feb 2012 06:22:12 +0100 In-Reply-To: <83ipjjb89i.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Feb 2012 06:02:49 +0200") Message-ID: <877gzz43qz.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eli Zaretskii writes: >> Maybe it can be integrated in the >> >> if (!(NILP(Vw32_get_true_file_attributes) ... >> >> hence reusing the calls to CreateFile and GetFileInformationByHandle and >> shortening the patch, but as I don't know what >> Vw32_get_true_file_attributes does, preferread to follow the safe way. > > You did right: w32-get-true-file-attributes can be set by the user to > nil, if she wants her file ops faster. I was thinking on something like diff --git a/src/w32.c b/src/w32.c index 3d3d334..418be63 100644 --- a/src/w32.c +++ b/src/w32.c @@ -3447,8 +3447,12 @@ stat (const char * path, struct stat * buf) } } - if (!(NILP (Vw32_get_true_file_attributes) - || (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow_fs (name))) + buf->st_size = 0; + + if ((!(NILP (Vw32_get_true_file_attributes) + || (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow_fs (name))) + || ((wfd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) && + (wfd.dwReserved0 == IO_REPARSE_TAG_SYMLINK))) /* No access rights required to get info. */ && (fh = CreateFile (name, 0, 0, NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL)) @@ -3461,6 +3465,9 @@ stat (const char * path, struct stat * buf) if (GetFileInformationByHandle (fh, &info)) { + buf->st_size = info.nFileSizeHigh; + buf->st_size <<= 32; + buf->st_size += info.nFileSizeLow; buf->st_nlink = info.nNumberOfLinks; /* Might as well use file index to fake inode values, but this is not guaranteed to be unique unless we keep a handle open @@ -3535,9 +3542,12 @@ stat (const char * path, struct stat * buf) buf->st_dev = volume_info.serialnum; buf->st_rdev = volume_info.serialnum; - buf->st_size = wfd.nFileSizeHigh; - buf->st_size <<= 32; - buf->st_size += wfd.nFileSizeLow; + if (!buf->st_size) + { + buf->st_size = wfd.nFileSizeHigh; + buf->st_size <<= 32; + buf->st_size += wfd.nFileSizeLow; + } /* Convert timestamps to Unix format. */ buf->st_mtime = convert_time (wfd.ftLastWriteTime); That is not as robust, though, because if GetFileInformationByHandle fails the function does not return with an error code. >> And the fix is just for the size. Don't know if there are other >> attributes suffer from the same problem. Possibly the right thing is to >> do what MSVCRT does: >> >> if is-symlink? >> use fstat >> fi > > Since fstat is also reimplemented, I'd rather do what it does inline. > > For that, we need to know which other attributes are reported > different. Or maybe just test for the reparse point up front and do > all the work for the target instead. Since Emacs' fstat reimplementation is based on GetFileInformationByHandle, and that the handle points to the linked file (CreateFile follows the link unless told otherwise), we should be safe delegating all work to `fstat' when a symlink is detected on `stat' (the executable bit must be setted on `stat', but that's no problem.) From unknown Wed Aug 20 05:16:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10733: 24.0.93; w32 file truncation Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Feb 2012 17:37: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: To: =?UTF-8?Q?=C3=93scar?= Fuentes Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10733-submit@debbugs.gnu.org id=B10733.13286362112488 (code B ref 10733); Tue, 07 Feb 2012 17:37:01 +0000 Received: (at 10733) by debbugs.gnu.org; 7 Feb 2012 17:36:51 +0000 Received: from localhost ([127.0.0.1]:59228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuoyI-0000e4-Jw for submit@debbugs.gnu.org; Tue, 07 Feb 2012 12:36:51 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:45706) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuoyG-0000dn-2F for 10733@debbugs.gnu.org; Tue, 07 Feb 2012 12:36:49 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LZ100000A14ER00@a-mtaout23.012.net.il> for 10733@debbugs.gnu.org; Tue, 07 Feb 2012 19:35:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.162.243]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LZ1000DTA6X83A0@a-mtaout23.012.net.il>; Tue, 07 Feb 2012 19:35:23 +0200 (IST) Date: Tue, 07 Feb 2012 19:35:25 +0200 From: Eli Zaretskii In-reply-to: <877gzz43qz.fsf@wanadoo.es> Message-id: <83bopabl7m.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il 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> <83sjinbyez.fsf@gnu.org> <87fwen4k6s.fsf@wanadoo.es> <83ipjjb89i.fsf@gnu.org> <877gzz43qz.fsf@wanadoo.es> X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: =D3scar Fuentes > Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.= org > Date: Tue, 07 Feb 2012 06:22:12 +0100 >=20 > Eli Zaretskii writes: >=20 > >> Maybe it can be integrated in the > >>=20 > >> if (!(NILP(Vw32_get_true_file_attributes) ... > >>=20 > >> hence reusing the calls to CreateFile and GetFileInformationByHa= ndle and > >> shortening the patch, but as I don't know what > >> Vw32_get_true_file_attributes does, preferread to follow the saf= e way. > > > > You did right: w32-get-true-file-attributes can be set by the use= r to > > nil, if she wants her file ops faster. >=20 > I was thinking on something like >=20 > diff --git a/src/w32.c b/src/w32.c > index 3d3d334..418be63 100644 > --- a/src/w32.c > +++ b/src/w32.c > @@ -3447,8 +3447,12 @@ stat (const char * path, struct stat * buf) > =09} > } > =20 > - if (!(NILP (Vw32_get_true_file_attributes) > -=09|| (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow_fs (n= ame))) > + buf->st_size =3D 0; > + > + if ((!(NILP (Vw32_get_true_file_attributes) > + || (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow= _fs (name))) > + || ((wfd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) &= & > + (wfd.dwReserved0 =3D=3D IO_REPARSE_TAG_SYMLINK))) Then what made you hesitate? This approach looks fine to me. > >> if is-symlink? > >> use fstat > >> fi > > > > Since fstat is also reimplemented, I'd rather do what it does inl= ine. > > > > For that, we need to know which other attributes are reported > > different. Or maybe just test for the reparse point up front and= do > > all the work for the target instead. >=20 > Since Emacs' fstat reimplementation is based on > GetFileInformationByHandle, and that the handle points to the linke= d > file (CreateFile follows the link unless told otherwise), we should= be > safe delegating all work to `fstat' when a symlink is detected on `= stat' > (the executable bit must be setted on `stat', but that's no problem= .) Please compare w32.c's `fstat' with `stat', and you will see that the former does much less than the latter, even with information that can be gotten by the handle. To go the way you suggest, we need first to make `fstat' a proper subset of `stat'. (I never had time to do it, and since `fstat' is used much less that `stat' in Emacs, more important jobs came first.) From unknown Wed Aug 20 05:16:38 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: "Ota, Takaaki" Subject: bug#10733: closed (Re: bug#10733: 24.0.93; w32 file truncation) Message-ID: References: <83pq78b5r2.fsf@gnu.org> <20120205.143400.416428493.Takaaki.Ota@am.sony.com> X-Gnu-PR-Message: they-closed 10733 X-Gnu-PR-Package: emacs Reply-To: 10733@debbugs.gnu.org Date: Fri, 03 Aug 2012 11:08:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1343992083-16610-1" This is a multi-part message in MIME format... ------------=_1343992083-16610-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #10733: 24.0.93; w32 file truncation which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 10733@debbugs.gnu.org. --=20 10733: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10733 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1343992083-16610-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 10733-done) by debbugs.gnu.org; 3 Aug 2012 11:07:59 +0000 Received: from localhost ([127.0.0.1]:58386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxFjZ-0004Jf-H6 for submit@debbugs.gnu.org; Fri, 03 Aug 2012 07:07:58 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:63001) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxFjW-0004JV-1v for 10733-done@debbugs.gnu.org; Fri, 03 Aug 2012 07:07:55 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M8600J00EIOMX00@a-mtaout21.012.net.il> for 10733-done@debbugs.gnu.org; Fri, 03 Aug 2012 13:59:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8600JQFEJRCLC0@a-mtaout21.012.net.il>; Fri, 03 Aug 2012 13:59:51 +0300 (IDT) Date: Fri, 03 Aug 2012 13:59:45 +0300 From: Eli Zaretskii Subject: Re: bug#10733: 24.0.93; w32 file truncation In-reply-to: <83bopabl7m.fsf@gnu.org> To: ofv@wanadoo.es, lekktu@gmail.com, Takaaki.Ota@am.sony.com Message-id: <83pq78b5r2.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il 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> <83sjinbyez.fsf@gnu.org> <87fwen4k6s.fsf@wanadoo.es> <83ipjjb89i.fsf@gnu.org> <877gzz43qz.fsf@wanadoo.es> <83bopabl7m.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 10733-done Cc: 10733-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 07 Feb 2012 19:35:25 +0200 > From: Eli Zaretskii > Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gnu.or= g >=20 > > From: =D3scar Fuentes > > Cc: lekktu@gmail.com, Takaaki.Ota@am.sony.com, 10733@debbugs.gn= u.org > > Date: Tue, 07 Feb 2012 06:22:12 +0100 > >=20 > > Eli Zaretskii writes: > >=20 > > >> Maybe it can be integrated in the > > >>=20 > > >> if (!(NILP(Vw32_get_true_file_attributes) ... > > >>=20 > > >> hence reusing the calls to CreateFile and GetFileInformationBy= Handle and > > >> shortening the patch, but as I don't know what > > >> Vw32_get_true_file_attributes does, preferread to follow the s= afe way. > > > > > > You did right: w32-get-true-file-attributes can be set by the u= ser to > > > nil, if she wants her file ops faster. > >=20 > > I was thinking on something like > >=20 > > diff --git a/src/w32.c b/src/w32.c > > index 3d3d334..418be63 100644 > > --- a/src/w32.c > > +++ b/src/w32.c > > @@ -3447,8 +3447,12 @@ stat (const char * path, struct stat * buf= ) > > =09} > > } > > =20 > > - if (!(NILP (Vw32_get_true_file_attributes) > > -=09|| (EQ (Vw32_get_true_file_attributes, Qlocal) && is_slow_fs = (name))) > > + buf->st_size =3D 0; > > + > > + if ((!(NILP (Vw32_get_true_file_attributes) > > + || (EQ (Vw32_get_true_file_attributes, Qlocal) && is_sl= ow_fs (name))) > > + || ((wfd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT)= && > > + (wfd.dwReserved0 =3D=3D IO_REPARSE_TAG_SYMLINK))) >=20 > Then what made you hesitate? This approach looks fine to me. >=20 > > >> if is-symlink? > > >> use fstat > > >> fi > > > > > > Since fstat is also reimplemented, I'd rather do what it does i= nline. > > > > > > For that, we need to know which other attributes are reported > > > different. Or maybe just test for the reparse point up front a= nd do > > > all the work for the target instead. > >=20 > > Since Emacs' fstat reimplementation is based on > > GetFileInformationByHandle, and that the handle points to the lin= ked > > file (CreateFile follows the link unless told otherwise), we shou= ld be > > safe delegating all work to `fstat' when a symlink is detected on= `stat' > > (the executable bit must be setted on `stat', but that's no probl= em.) >=20 > Please compare w32.c's `fstat' with `stat', and you will see that t= he > former does much less than the latter, even with information that c= an > be gotten by the handle. To go the way you suggest, we need first = to > make `fstat' a proper subset of `stat'. (I never had time to do it= , > and since `fstat' is used much less that `stat' in Emacs, more > important jobs came first.) Since trunk revision 109416 adds full support for symlinks on MS-Windows platforms, and fixes this bug as a side effect, I'm closin= g this bug. ------------=_1343992083-16610-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Feb 2012 22:35:07 +0000 Received: from localhost ([127.0.0.1]:55921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuAfq-0002Oj-HV for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:35:07 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56967) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RuAfn-0002OE-6g for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:35:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuAew-0003uX-5k for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:34:11 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RECEIVED_FROM_WINDOWS_HOST autolearn=no version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:40152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuAew-0003uT-4H for submit@debbugs.gnu.org; Sun, 05 Feb 2012 17:34:10 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuAeu-0008TY-UI for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2012 17:34:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuAes-0003tW-DQ for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2012 17:34:08 -0500 Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:15954 helo=VA3EHSOBE009.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuAes-0003tB-8e for bug-gnu-emacs@gnu.org; Sun, 05 Feb 2012 17:34:06 -0500 Received: from mail157-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Feb 2012 22:34:04 +0000 Received: from mail157-va3 (localhost [127.0.0.1]) by mail157-va3-R.bigfish.com (Postfix) with ESMTP id B3788300380 for ; Sun, 5 Feb 2012 22:34:04 +0000 (UTC) X-SpamScore: -9 X-BigFish: VPS-9(z21eNz936eKzz1202hzzz2fh668h839h944h) 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 (mail157-va3: 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 ; Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3 (MessageSwitch) id 1328481243245735_13019; Sun, 5 Feb 2012 22:34:03 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.241]) by mail157-va3.bigfish.com (Postfix) with ESMTP id 333A1E0046 for ; Sun, 5 Feb 2012 22:34:03 +0000 (UTC) Received: from mail7.fw-bc.sony.com (160.33.98.74) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 5 Feb 2012 22:34:02 +0000 Received: from mail2x.bc.in.sel.sony.com (mail.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 q15MY2dv001734 for ; Sun, 5 Feb 2012 22:34:02 GMT Received: from localhost ([43.142.224.238]) by mail2x.bc.in.sel.sony.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id q15MY1b8020302 for ; Sun, 5 Feb 2012 22:34:01 GMT Date: Sun, 5 Feb 2012 14:34:00 -0800 Message-ID: <20120205.143400.416428493.Takaaki.Ota@am.sony.com> To: Subject: 24.0.93; w32 file truncation From: "Ota, Takaaki" X-Mailer: Mew-6.3.50 on Emacs-24.0.93.1 (i386-mingw-nt6.1.7601 built on 2012-01-29) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginatorOrg: am.sony.com X-detected-operating-system: by eggs.gnu.org: Windows XP/2000 (RFC1323+, w+, tstamp-) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) When opening a file on an NTFS file system the file opens as if the content is truncated to size of 65375 characters. This happens when the file is an NTFS symbolic link which is made by mklink command of cmd.exe. There is no problem if the target file of the NTFS symbolic link is smaller than this size. -Tak --text follows this line-- This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgement at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file c:/emacs/emacs-24.0.93/etc/DEBUG. In GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601) of 2012-01-29 on TAK-VAIO-Z1290 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --with-gcc (4.5) --cflags -Ic:/d/pub/emacs/include --ldflags -Lc:/d/pub/emacs/lib' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: ESC x f i n d SPC f i SPC m e m o ESC : ( p o i n t ) ESC : r e p o r t SPC C-g ESC x r e p o r SPC e m SPC SPC Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. You can run the command `find-file' with C-x C-f scroll-up-command: End of buffer [21 times] byte-code: End of buffer [21 times] 65375 (#o177537, #xff5f) Quit Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer button faces cus-face files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty emacs) ------------=_1343992083-16610-1--