Subject: Re: bug#35497: [PATCH] Don't rewrite buffer contents after saving by rename

From: Eli Zaretskii <[email-masked]>
Date: Wed, 01 May 2019 20:48:41 +0300

> From: Jonathan Tomer <[email-masked]>
> Date: Tue, 30 Apr 2019 14:10:32 -0700
> Cc: [email-masked]
> 
>  Btw, your new test in files-tests.el uses file notifications. Possible
>  of course. But wouldn't it be more robust to check the inode number of
>  the involved files, and how it changes, or not? See file-attributes how
>  to retrieve the inode number of a file.
> 
> 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 suggest to make a step back and clearly define what you are trying
to test.  Is it that we don't rewrite the file after saving it, or is
it some condition regarding the inodes of the original and the new
file?

These are two different things, and the second one is extremely
platform-dependent (because inodes exist only in certain filesystems,
and are emulated in others, and also because which notifications are
generated in such complex situations is very hard to guess in
advance).