unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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)?

  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).