DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	b=GCqm4q+liH4aghzYHFOWES8l0JCauqp/tcngUpHdK/+p0paXQdr2HaN3X+c/vbBo0V
	cgHj+PFWkUcCiD78h0Kgs8ylAu0rKPgo8WhPbxRsE6ziFh6ugSg2LqpHK7VhW/X9s5+p
	hPhDkxiDF1l6d3ph/IFaejrR5DroM+OMXLrLA=
MIME-Version: 1.0
In-Reply-To: <87sjz1dr0j.fsf@yoom.home.cworth.org>
References: <AANLkTikKiKC716H+ddF0Q5T0xc=vGHHOVroLRwzO3ujV@mail.gmail.com>
	<87sjz1dr0j.fsf@yoom.home.cworth.org>
From: "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com>
Date: Tue, 16 Nov 2010 22:26:56 +0200
Message-ID: <AANLkTikrXdp5OOCw2Avs8ao9Ukpq8szsdP9FFZP+eYNK@mail.gmail.com>
Subject: Re: `notmuch setup` replaces `~/.notmuch-config` instead of
	truncating it
To: Carl Worth <cworth@cworth.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

On Tue, Nov 16, 2010 at 21:09, Carl Worth <cworth@cworth.org> wrote:
> On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun" <ciprian.cra=
ciun@gmail.com> wrote:
>> =C2=A0 =C2=A0 So my question is: is this behaviour (of deleting the file=
 and
>> creating a new one) deliberate? If not, could it be fixed (I could
>> provide a patch) to just update the file in place?
>
> Daniel gave the perfect answer later in the thread. It is intentional to
> replace the file with a new, complete version, (to avoid loss/corruption
> of the file if "notmuch setup" is interrupted). But we should fix this
> to replace the target of any symlinks.
>
> -Carl


    I understand now the reason for your file replacement choice.
(I'll look over tomorrow to see if I can provide a patch on the line
Daniel has described).

    But -- in general, and totally overlooking the "pseudo" atomic
effect obtained from of POSIX file semantics -- doesn't this practice
mislead some software (like backup systems, etc.) that would rely
maybe on the inode number as part of the identity of the file?
Moreover what if the user has set any ACL's or extended attributes on
the file, wouldn't these be lost? (Wouldn't also SELinux be bothered?)

    So after browsing through the source code, I've found inside
`notmuch-config.c`, inside the function `notmuch_config_save`, the
call which actually overrides the file: `g_file_set_contents
(config->filename, data, length, &error)`. Now searching for the
documentation of this function, I've stumbled upon, from which I cite
(I've never used glib before, so maybe the link is not the best one):
        http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.ht=
ml
~~~~
On Unix, if filename already exists hard links to filename will break.
Also since the file is recreated, existing permissions, access control
lists, metadata etc. may be lost. If filename is a symbolic link, the
link itself will be replaced, not the linked file.
~~~~

    So in the light of the above quoted "glitches", my question is:
due to the small chance of a power loss happening right when we write
such a small file, doesn't the inconvenience weight more than the
(fairly remote probable) file loss? (I must admit I've lost once the
`/etc/network/interfaces` file after an edit and immediately after a
quick cold reboot, but it was my fault as I've not sync-ed the file
system.)

    Ciprian.

    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.)