From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.help Subject: Re: Emacs opens only first 16384 bytes of file?! Date: Sun, 12 Feb 2023 05:55:41 +0100 Message-ID: <87mt5jscs2.fsf@telefonica.net> References: <87h6vrucl7.fsf@drac> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10222"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: help-gnu-emacs@gnu.org To: Christoph Groth Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 12 05:56:36 2023 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pR4Pk-0002Ux-2K for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 12 Feb 2023 05:56:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pR4P7-0006ZW-T1; Sat, 11 Feb 2023 23:55:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pR4P6-0006ZO-QS for help-gnu-emacs@gnu.org; Sat, 11 Feb 2023 23:55:56 -0500 Original-Received: from relayout02.e.movistar.es ([86.109.101.202] helo=relayout02-redir.e.movistar.es) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pR4P4-0004WR-2K for help-gnu-emacs@gnu.org; Sat, 11 Feb 2023 23:55:56 -0500 Original-Received: from sky (73.red-81-39-121.dynamicip.rima-tde.net [81.39.121.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout02.e.movistar.es (Postfix) with ESMTPSA id 4PDwCL3qQDzdZPY; Sun, 12 Feb 2023 05:55:42 +0100 (CET) In-Reply-To: <87h6vrucl7.fsf@drac> (Christoph Groth's message of "Sat, 11 Feb 2023 22:16:52 +0100") X-TnetOut-Country: IP: 81.39.121.73 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-TnetOut-MsgID: 4PDwCL3qQDzdZPY.A8395 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1676782548.12195@Or5TtqdEWE+CEZvI9DLG+g Received-SPF: softfail client-ip=86.109.101.202; envelope-from=ofv@wanadoo.es; helo=relayout02-redir.e.movistar.es X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, PLING_QUERY=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142719 Archived-At: Christoph Groth writes: > Hello, > > I just noticed something that made me doubt my own sanity: With Emacs > 27.1 (from Debian stable running Debian=E2=80=99s Linux kernel > 6.0.0-0.deb11.6-amd64) the command > > emacs -q -nw /proc/cpuinfo > > reproducibly opens cpuinfo only up to a portion of line 272, while the > entire file is 560 lines long on that machine. I checked on a different > machine (with same Emacs), and I see the same behavior. > > C-u C-x =3D tells that the file is read up to position 16384 (=3D 2^14). > > Running M-x revert-buffer loads the whole file... > > Is/was this a known issue? I could not find anything on the web. > > ---------------------------------------------------------------- > > I=E2=80=99m willing to investigate this further, but it would seem very s= trange > if Emacs indeed had a bug that prevented it from loading some files > entirely. Perhaps someone here knows the answer. As of today (Emacs 30, current development branch) the same is true. /proc/cpuinfo is not a regular file, in the sense that its content is not stored in a device. AFAIK it is generated on-the-fly when it is read. You can do some simple observations: $ ls -l /proc/cpuinfo=20 -r--r--r-- 1 root root 0 feb 7 03:34 /proc/cpuinfo $ du /proc/cpuinfo=20 0 /proc/cpuinfo Here those tools are saying that the file's size is 0. I guess that Emacs detects that the file is special and reads its contents following some heuristics. What surprises me is that M-x revert-file actually reads all the content. Of course, looking at the sources would be enlightening, but why do the effort of actually clearing the matter when it is so cheap to throw speculation? ;-) (I looked at insert-file-contents, but bailed out after the fifth screenful of code. A 1000+ lines function, no kidding.)