98/bacd75503649731648c5983e6bda9946bf6711

   1 Return-Path: <ciprian.craciun@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 35BDF40DBFE\r
   6         for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:27:43 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.999\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,\r
  13         DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001]\r
  14         autolearn=unavailable\r
  15 Received: from olra.theworths.org ([127.0.0.1])\r
  16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17         with ESMTP id M-cv0HjCr0BB for <notmuch@notmuchmail.org>;\r
  18         Tue, 16 Nov 2010 12:27:31 -0800 (PST)\r
  19 Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com\r
  20         [209.85.212.53])\r
  21         by olra.theworths.org (Postfix) with ESMTP id 307F240DBFA\r
  22         for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:27:31 -0800 (PST)\r
  23 Received: by vws7 with SMTP id 7so658367vws.26\r
  24         for <notmuch@notmuchmail.org>; Tue, 16 Nov 2010 12:27:27 -0800 (PST)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:received:mime-version:received:in-reply-to\r
  27         :references:from:date:message-id:subject:to:cc:content-type\r
  28         :content-transfer-encoding;\r
  29         bh=7o/Ss+r3icQeFKRDTQ1w/AKW3QnXEOFxjPc4kZPqj5s=;\r
  30         b=ngouzv2Fkc3eqojmYoetb2DjDR/NrAk9Pejum9fjo40tJVhFjsx4z1nCE1SXV9CD+M\r
  31         2iA2v8fF2hTJ+/TYJ8k4mf2lqYqBQr6lj6LmYVIDzph6/tzUGDg6XDKXkbg2DLP0gUaI\r
  32         ZWb5ho8yWhdcNWfPVWQ5+tZBiJFe5tBJN9Zj0=\r
  33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  34         h=mime-version:in-reply-to:references:from:date:message-id:subject:to\r
  35         :cc:content-type:content-transfer-encoding;\r
  36         b=GCqm4q+liH4aghzYHFOWES8l0JCauqp/tcngUpHdK/+p0paXQdr2HaN3X+c/vbBo0V\r
  37         cgHj+PFWkUcCiD78h0Kgs8ylAu0rKPgo8WhPbxRsE6ziFh6ugSg2LqpHK7VhW/X9s5+p\r
  38         hPhDkxiDF1l6d3ph/IFaejrR5DroM+OMXLrLA=\r
  39 Received: by 10.229.191.130 with SMTP id dm2mr6566897qcb.256.1289939247246;\r
  40         Tue, 16 Nov 2010 12:27:27 -0800 (PST)\r
  41 MIME-Version: 1.0\r
  42 Received: by 10.229.189.17 with HTTP; Tue, 16 Nov 2010 12:26:56 -0800 (PST)\r
  43 In-Reply-To: <87sjz1dr0j.fsf@yoom.home.cworth.org>\r
  44 References: <AANLkTikKiKC716H+ddF0Q5T0xc=vGHHOVroLRwzO3ujV@mail.gmail.com>\r
  45         <87sjz1dr0j.fsf@yoom.home.cworth.org>\r
  46 From: "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com>\r
  47 Date: Tue, 16 Nov 2010 22:26:56 +0200\r
  48 Message-ID: <AANLkTikrXdp5OOCw2Avs8ao9Ukpq8szsdP9FFZP+eYNK@mail.gmail.com>\r
  49 Subject: Re: `notmuch setup` replaces `~/.notmuch-config` instead of\r
  50         truncating it\r
  51 To: Carl Worth <cworth@cworth.org>\r
  52 Content-Type: text/plain; charset=UTF-8\r
  53 Content-Transfer-Encoding: quoted-printable\r
  54 Cc: notmuch@notmuchmail.org\r
  55 X-BeenThere: notmuch@notmuchmail.org\r
  56 X-Mailman-Version: 2.1.13\r
  57 Precedence: list\r
  58 List-Id: "Use and development of the notmuch mail system."\r
  59         <notmuch.notmuchmail.org>\r
  60 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  62 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  63 List-Post: <mailto:notmuch@notmuchmail.org>\r
  64 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  65 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  67 X-List-Received-Date: Tue, 16 Nov 2010 20:27:43 -0000\r
  68 \r
  69 On Tue, Nov 16, 2010 at 21:09, Carl Worth <cworth@cworth.org> wrote:\r
  70 > On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun" <ciprian.cra=\r
  71 ciun@gmail.com> wrote:\r
  72 >> =C2=A0 =C2=A0 So my question is: is this behaviour (of deleting the file=\r
  73  and\r
  74 >> creating a new one) deliberate? If not, could it be fixed (I could\r
  75 >> provide a patch) to just update the file in place?\r
  76 >\r
  77 > Daniel gave the perfect answer later in the thread. It is intentional to\r
  78 > replace the file with a new, complete version, (to avoid loss/corruption\r
  79 > of the file if "notmuch setup" is interrupted). But we should fix this\r
  80 > to replace the target of any symlinks.\r
  81 >\r
  82 > -Carl\r
  83 \r
  84 \r
  85     I understand now the reason for your file replacement choice.\r
  86 (I'll look over tomorrow to see if I can provide a patch on the line\r
  87 Daniel has described).\r
  88 \r
  89     But -- in general, and totally overlooking the "pseudo" atomic\r
  90 effect obtained from of POSIX file semantics -- doesn't this practice\r
  91 mislead some software (like backup systems, etc.) that would rely\r
  92 maybe on the inode number as part of the identity of the file?\r
  93 Moreover what if the user has set any ACL's or extended attributes on\r
  94 the file, wouldn't these be lost? (Wouldn't also SELinux be bothered?)\r
  95 \r
  96     So after browsing through the source code, I've found inside\r
  97 `notmuch-config.c`, inside the function `notmuch_config_save`, the\r
  98 call which actually overrides the file: `g_file_set_contents\r
  99 (config->filename, data, length, &error)`. Now searching for the\r
 100 documentation of this function, I've stumbled upon, from which I cite\r
 101 (I've never used glib before, so maybe the link is not the best one):\r
 102         http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.ht=\r
 103 ml\r
 104 ~~~~\r
 105 On Unix, if filename already exists hard links to filename will break.\r
 106 Also since the file is recreated, existing permissions, access control\r
 107 lists, metadata etc. may be lost. If filename is a symbolic link, the\r
 108 link itself will be replaced, not the linked file.\r
 109 ~~~~\r
 110 \r
 111     So in the light of the above quoted "glitches", my question is:\r
 112 due to the small chance of a power loss happening right when we write\r
 113 such a small file, doesn't the inconvenience weight more than the\r
 114 (fairly remote probable) file loss? (I must admit I've lost once the\r
 115 `/etc/network/interfaces` file after an edit and immediately after a\r
 116 quick cold reboot, but it was my fault as I've not sync-ed the file\r
 117 system.)\r
 118 \r
 119     Ciprian.\r
 120 \r
 121     P.S.: I say "pseudo" atomic because only the rename is atomic,\r
 122 thus in order to override file `a` for the target file `b` which\r
 123 exists, we must execute two **non-atomic** operations as a whole, but\r
 124 each atomic in part, rename operations: make `b` -> `c`, and then\r
 125 rename `a` -> `b`. So there is actually a small time-frame when I can\r
 126 be left with two files (`a` and `c`), none of which is my config file\r
 127 `b`. (This can be solved when opening the config file by checking if\r
 128 there isn't any leftover `c` or `a` file, in which case I take the `a`\r
 129 file and complete the rename.)\r