From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christoph Groth Newsgroups: gmane.emacs.help Subject: Re: Emacs opens only first 16384 bytes of file?! Date: Sun, 12 Feb 2023 10:58:14 +0100 Message-ID: <87cz6ftdc9.fsf@drac> References: <87h6vrucl7.fsf@drac> <87mt5jscs2.fsf@telefonica.net> 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="18392"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , help-gnu-emacs@gnu.org To: Ruijie Yu Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 12 10:59:19 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 1pR98h-0004Su-BM for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 12 Feb 2023 10:59:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pR97q-00031w-4i; Sun, 12 Feb 2023 04:58:26 -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 1pR97n-00031f-1A for help-gnu-emacs@gnu.org; Sun, 12 Feb 2023 04:58:23 -0500 Original-Received: from dia.uberspace.de ([185.26.156.221]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pR97j-0001Mc-St for help-gnu-emacs@gnu.org; Sun, 12 Feb 2023 04:58:21 -0500 Original-Received: (qmail 7296 invoked by uid 989); 12 Feb 2023 09:58:16 -0000 Authentication-Results: dia.uberspace.de; auth=pass (plain) In-Reply-To: (Ruijie Yu's message of "Sun, 12 Feb 2023 13:56:48 +0800") X-Rspamd-Bar: / X-Rspamd-Report: MIME_GOOD(-0.1) BAYES_HAM(-0.811455) MID_RHS_NOT_FQDN(0.5) X-Rspamd-Score: -0.411455 Original-Received: from unknown (HELO unkown) (::1) by dia.uberspace.de (Haraka/3.0.1) with ESMTPSA; Sun, 12 Feb 2023 10:58:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=grothesque.org; s=uberspace; h=from; bh=5lviYwQYCms4+pZnGVejUW3xcF4qIz6K5rJJoEfuANo=; b=MW0XdMz01Ry9u+OLociDGACb5wMSX4Wm2eFejFo6yCo+YakhLFAruwkMCqJXy6FtxwAQoXEuCw Ab4uRO9CTLYzsYkbr3VARQHeIZs0ikANVyaJ7hSAZyW3ws8I8NgLhnhjAwkG0fvK84KGCIPQG5CW VktEPyk1yA7EDj5jkSh8G8vkn002yTXOqAY2sTLrCUWyTT1xh7WX+PNINwOUR6msA47+VI006GMN 8lOaFGw/y60WSbO0Ir38gg8bdyNFh4ZUoWZW7R3jUANKozetAjYu/UsS72ok8gyPspLIdpB1bZjG szhtu1YZAIfsV1XpGE58H6rbl40dLfl/5JtpfgPEAHSNezaNL3yUsSJOOysmZUFuf1c/B/tsYLKY /oI3AdGpVoA7Lx569jdpqSv9wYffktJ0Z+kXsx/TROUVvFSHxxa0JBVnZsRAm6pJgW4Wfo3yXf6f ZSOXYSvkpLn3ejJ5yIPpg+GTziIjWiWgeRYff4DiPp07pIFqUj69RuQN8Wp8FqcG4DoxREttIs4z J2kVM6dlbnh6e//M4T9uFy5fUNivrQrexANkVx5sfJgW/XJBEhkMT6x9sps+P1gp7yxV+GsvnyLb tV1XshITQCs0KjPqQnjlW6r/ASMSAgcNtWSX9lYtRwJaUxPrrH2anQHnARQNRBpc0fYW3DLlwIEb Q= Received-SPF: pass client-ip=185.26.156.221; envelope-from=christoph@grothesque.org; helo=dia.uberspace.de X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, PLING_QUERY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:142724 Archived-At: Ruijie Yu wrote: > =C3=93scar Fuentes writes: > > > [...] > > 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 > > -r--r--r-- 1 root root 0 feb 7 03:34 /proc/cpuinfo > > $ du /proc/cpuinfo > > 0 /proc/cpuinfo > > > > Here those tools are saying that the file's size is 0. > > Thanks for elaborating on the part that I missed. So, to reproduce > the issue, we need to find a file which does not show size, and whose > contents are generated on-the-fly when read -- in the original report, > it is /proc/cpuinfo, and I have also found /proc/kallsyms which > contains around 12M of data. In this case, I have reproduced the > issue on my Emacs 29 build. Yes, that=E2=80=99s it, thanks for examining this further! > > 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 think the limit of 16384 is probably caused by fileio.c:3919 > (907fd1f7ff4 somewhere on master, inside DEFUN "insert-file-contents") > which declares a read buffer. The constant READ_BUF_SIZE is > indirectly set as 16 * 1024 =3D 16384. Didn't read further there, nor > inside `revert-buffer'. Indeed this seems to be related to the advertised file size being zero. However, no other programs (including editors) seem to have a problem with this. So it really must be Emacs trying to be clever. Finding files under /proc/ is, of course, not a very relevant application of Emacs, but Elisp code gets posted that relies on this: https://nullprogram.com/blog/2015/10/14/ I had something similar in my init.el to determine the value to use with "make -j" as a default compile command - this is how I noticed this issue in the first place. (Now I changed that to executing the command nproc.) What worries me more is that there may be other, more sneaky, cases where this backfires. For example, perhaps opening a file that is being written (so that its size increases), is broken as well in some cases? Should I report this to bug-gnu-emacs@gnu.org, or is posting on this list enough? Or should I open a ticket with debbugs.gnu.org? Cheers Christoph