Re: `notmuch setup` replaces `~/.notmuch-config` instead of truncating it

["Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com>]

On Tue, Nov 16, 2010 at 22:37, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>>     P.S.: I say "pseudo" atomic because only the rename is atomic,
>> thus in order to override file `a` for the target file `b` which
>> exists, we must execute two **non-atomic** operations as a whole, but
>> each atomic in part, rename operations: make `b` -> `c`, and then
>> rename `a` -> `b`. So there is actually a small time-frame when I can
>> be left with two files (`a` and `c`), none of which is my config file
>> `b`. (This can be solved when opening the config file by checking if
>> there isn't any leftover `c` or `a` file, in which case I take the `a`
>> file and complete the rename.)
>
> There is only one ".notmuch-config" entry in the inode directory that is
> your homedir.  it points either to the old file, or the new file.  it
> cannot point to both, and it will not point to anything but those two
> possibilities.  This is what the atomicity of the operation is expected
> to guarantee.
>
>        --dkg


    Actually I've been wrong about this... I've thought that the way
the file is "overwritten" is actually done by either two `rename`
calls or by `link`, followed by another `link`, and then finally an
`unlink` (this is what I've tried to explain in my previous email).

    In fact I've thought that the `rename` OS call can't overwrite a
file if it exists.

    But after reading the man page of `rename(2)` -- quoted below -- I
was indeed wrong to call the atomicity as being "pseudo".

~~~~
       int rename(const char *oldpath, const char *newpath);
...
       If newpath already exists it will be atomically replaced
(subject to a few conditions; see ERRORS below),  so  that  there  is
no
       point at which another process attempting to access newpath
will find it missing.
...
       If newpath exists but the operation fails for some reason
rename() guarantees to leave an instance of newpath in place.
~~~~

    So indeed the behavior is completely atomic.

    Ciprian.