From: Ruijie Yu via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: Christoph Groth <christoph@grothesque.org>, help-gnu-emacs@gnu.org
Subject: Re: Emacs opens only first 16384 bytes of file?!
Date: Sun, 12 Feb 2023 13:56:48 +0800 [thread overview]
Message-ID: <sdv357bo1ak.fsf@fw.net.yu> (raw)
In-Reply-To: <87mt5jscs2.fsf@telefonica.net>
Óscar Fuentes <ofv@wanadoo.es> 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.
> 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 = 16384. Didn't read further there, nor inside
`revert-buffer'.
> (I looked at insert-file-contents, but bailed out after the fifth
> screenful of code. A 1000+ lines function, no kidding.)
Yeah, that's exactly why I didn't read further there.
--
Best,
RY
next prev parent reply other threads:[~2023-02-12 5:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 21:16 Emacs opens only first 16384 bytes of file?! Christoph Groth
2023-02-12 3:55 ` Ruijie Yu via Users list for the GNU Emacs text editor
2023-02-12 4:55 ` Óscar Fuentes
2023-02-12 5:56 ` Ruijie Yu via Users list for the GNU Emacs text editor [this message]
2023-02-12 9:58 ` Christoph Groth
2023-02-12 11:45 ` Eli Zaretskii
2023-02-12 6:02 ` Eli Zaretskii
2023-02-12 7:11 ` tomas
2023-02-12 7:33 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2023-02-13 7:59 Christoph Groth
2023-02-13 13:06 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sdv357bo1ak.fsf@fw.net.yu \
--to=help-gnu-emacs@gnu.org \
--cc=christoph@grothesque.org \
--cc=ofv@wanadoo.es \
--cc=ruijie@netyu.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).