From: Michael Albinus <michael.albinus@gmx.de>
To: Jonathan Tomer <jktomer@google.com>
Cc: 35497@debbugs.gnu.org
Subject: bug#35497: [PATCH] Don't rewrite buffer contents after saving by rename
Date: Tue, 30 Apr 2019 23:21:26 +0200 [thread overview]
Message-ID: <87h8afw5nt.fsf@gmx.de> (raw)
In-Reply-To: <CAHY_+qxKj+GeVbRLQSTdX6xYN6ho=Sa+UC7XKi_SmX-FihFFQw@mail.gmail.com> (Jonathan Tomer's message of "Tue, 30 Apr 2019 14:10:32 -0700")
Jonathan Tomer <jktomer@google.com> writes:
Hi Jonathan,
> I thought about checking that the inode number changes, but that
> wouldn't have caught this particular bug (where the file is renamed
> into place with the correct contents, and then rewritten in place
> again); indeed, that doesn't appear to be easily caught with any
> examination of the final state alone, since what we're looking for is
> to prove the *absence* of any write that fails to change the inode
> number. (Perhaps we could check that the modification time of the
> file, after write, is *less* than its inode change time, proving that
> there has been no ordinary write since the rename -- but in my
> experience, inode timestamps are not actually more reliable than
> inotify, and in particular this check is easily defeated by the
> mode-setting that happens after the write is complete, requiring care
> to make sure that save-buffer will not attempt to do so.)
I see. But pls keep in mind, that inotify is not the only file
notification backend. Currently, we have six different beasts for this.
> Best,
> Jonathan
Best regards, Michael.
next prev parent reply other threads:[~2019-04-30 21:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 23:20 bug#35497: [PATCH] Don't rewrite buffer contents after saving by rename Jonathan Tomer
2019-04-30 7:18 ` Michael Albinus
2019-04-30 19:27 ` Jonathan Tomer
2019-04-30 20:47 ` Michael Albinus
2019-04-30 21:10 ` Jonathan Tomer
2019-04-30 21:21 ` Michael Albinus [this message]
2019-04-30 22:42 ` Jonathan Tomer
2019-05-01 0:26 ` bug#35497: [PATCH v2] " Jonathan Tomer
2019-05-01 17:48 ` bug#35497: [PATCH] " Eli Zaretskii
2019-05-01 19:29 ` Jonathan Tomer
2019-05-01 19:54 ` Eli Zaretskii
2019-05-01 19:56 ` Jonathan Tomer
2019-05-01 23:02 ` bug#35497: [PATCH v3] " Jonathan Tomer
2019-05-02 11:50 ` Michael Albinus
2019-05-02 22:04 ` Jonathan Tomer
2019-05-02 22:06 ` bug#35497: [PATCH v4] " Jonathan Tomer
2019-05-03 7:52 ` Michael Albinus
2019-05-03 12:29 ` Eli Zaretskii
2019-05-06 20:45 ` Jonathan Tomer
2019-05-07 14:05 ` Michael Albinus
2019-05-07 23:46 ` Richard Stallman
2019-05-06 20:46 ` bug#35497: [PATCH v5] " Jonathan Tomer
2019-05-06 20:48 ` bug#35497: [PATCH v6] " Jonathan Tomer
2019-05-07 14:03 ` Michael Albinus
2019-05-07 14:10 ` Michael Albinus
2019-05-07 17:25 ` Jonathan Tomer
2019-05-07 17:33 ` bug#35497: [PATCH v7] " Jonathan Tomer
2019-05-08 7:48 ` Michael Albinus
2019-05-08 17:03 ` Jonathan Tomer
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8afw5nt.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=35497@debbugs.gnu.org \
--cc=jktomer@google.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.