From: Evil Boris <evilborisnet@netscape.net>
Subject: Re: RMAIL file locking problem?
Date: Mon, 09 May 2005 23:03:45 -0400 [thread overview]
Message-ID: <umzr36aum.fsf@boris.laptop> (raw)
In-Reply-To: E1DSO0b-0008TC-6w@fencepost.gnu.org
Richard Stallman <rms@gnu.org> writes:
> Or could one check the C code for "insert-file-contents"? Does it
> mark the buffer modified if 0 bytes were read.
>
> The code appears specifically to avoid marking the buffer modified
> if the file has zero size. I just did a test, inserting an empty
> file into a buffer this way. It did not mark the buffer modified
> and did not lock the file.
>
> Something we don't understand must be happening, and only you
> are in a position to debug it.
I have spent some time tracing the code of insert-file-contents. I do
not understand what it is trying to do, to be honest, but this is what
it **appears** to be doing: If the file it is trying to read has ZERO
bytes according to what stat() returns, it does the following:
----lines 176-181 of fileio.c
/* The file size returned from stat may be zero, but data
may be readable nonetheless, for example when this is a
file in the /proc filesystem. */
if (st.st_size == 0)
XSETINT (end, READ_BUF_SIZE);
---------
This has the effect of setting the amount to be read to non-zero.
Around line 707 it does
total = XINT (end) - XINT (beg);
setting total to something very much other than zero (some buffer
size), and in the next if statement (line 718)
if (NILP (visit) && total > 0)
prepare_to_modify_buffer (PT, PT, NULL);
which as far as I can tell calls lock_file on the underlying file.
Any other suggestions/ideas?
--Boris
PS. I can see the comment in fileio.c regarding /proc and can guess
that this sometimes might come in handy, but I do not see why reading
a regular zero-byte file should force a modification and/or locking of
the current buffer. But if I am right, I do not see how reading a
zero-byte file can EVER work right. Richard said he tried some casual
tests and it seems to work. I just tried creating a file qqqq in /tmp,
visiting it, and doing (insert-file-contents "/var/mail/whatever") and
lo and behold, a lock file for /tmp/qqqq showed up! Just tried it
again with /tmp/empty in place of /var/mail/whatever---same effect.
Does it mean that 0-size insertion is just broken on my machine
(Solaris 5.7, gcc 3.1)?
next prev parent reply other threads:[~2005-05-10 3:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 16:16 RMAIL file locking problem? Evil Boris
2005-04-20 14:56 ` Richard Stallman
2005-04-28 4:03 ` Evil Boris
2005-04-29 0:13 ` Richard Stallman
2005-04-30 20:05 ` Evil Boris
2005-05-01 23:37 ` Richard Stallman
2005-05-10 3:03 ` Evil Boris [this message]
2005-05-11 16:28 ` Richard Stallman
2005-05-12 0:32 ` Evil Boris
2005-05-12 14:54 ` Richard Stallman
2005-05-14 3:46 ` Evil Boris
2005-05-14 15:13 ` Richard Stallman
2005-05-14 4:17 ` Evil Boris
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=umzr36aum.fsf@boris.laptop \
--to=evilborisnet@netscape.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).