diff options
Diffstat (limited to 'tickets/829d5f9060144a30bd44cb946b0ba1c9/Maildir/new/1455998995.M78975P17339Q22.exolobe1')
| -rw-r--r-- | tickets/829d5f9060144a30bd44cb946b0ba1c9/Maildir/new/1455998995.M78975P17339Q22.exolobe1 | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/tickets/829d5f9060144a30bd44cb946b0ba1c9/Maildir/new/1455998995.M78975P17339Q22.exolobe1 b/tickets/829d5f9060144a30bd44cb946b0ba1c9/Maildir/new/1455998995.M78975P17339Q22.exolobe1 new file mode 100644 index 0000000..d4b538d --- /dev/null +++ b/tickets/829d5f9060144a30bd44cb946b0ba1c9/Maildir/new/1455998995.M78975P17339Q22.exolobe1 @@ -0,0 +1,124 @@ +Return-Path: <obnam-dev-bounces@obnam.org> +X-Original-To: distix@pieni.net +Delivered-To: distix@pieni.net +Received: from bagpuss.pepperfish.net (bagpuss.pepperfish.net [148.251.8.16]) + (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by pieni.net (Postfix) with ESMTPS id DA854228E5 + for <distix@pieni.net>; Sun, 27 Sep 2015 14:35:21 +0200 (CEST) +Received: from platypus.pepperfish.net (unknown [10.112.100.20]) + by bagpuss.pepperfish.net (Postfix) with ESMTP id 3AE77CC8; + Sun, 27 Sep 2015 13:35:21 +0100 (BST) +Received: from ip6-localhost ([::1] helo=platypus.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1ZgBAn-0004ev-2p; Sun, 27 Sep 2015 13:35:21 +0100 +Received: from inmail0 ([10.112.100.10] helo=mx0.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1ZgBAl-0004en-Jl + for <obnam-dev@obnam.org>; Sun, 27 Sep 2015 13:35:19 +0100 +Received: from mailout.easymail.ca ([64.68.201.169]) + by mx0.pepperfish.net with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) + (Exim 4.80) (envelope-from <hsivonen@hsivonen.fi>) + id 1ZgBAj-0008WH-B5 + for obnam-dev@obnam.org; Sun, 27 Sep 2015 13:35:19 +0100 +Received: from localhost (localhost [127.0.0.1]) + by mailout.easymail.ca (Postfix) with ESMTP id 1C109E5F5 + for <obnam-dev@obnam.org>; Sun, 27 Sep 2015 08:35:07 -0400 (EDT) +X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca +X-Spam-Flag: NO +X-Spam-Score: -3.68 +X-Spam-Level: +X-Spam-Status: No, score=-3.68 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.027, + BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692] +Received: from mailout.easymail.ca ([127.0.0.1]) + by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, + port 10024) with ESMTP id m8jySb3LrAFt for <obnam-dev@obnam.org>; + Sun, 27 Sep 2015 08:35:06 -0400 (EDT) +Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com + [209.85.213.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by mailout.easymail.ca (Postfix) with ESMTPSA id 1387FE5D3 + for <obnam-dev@obnam.org>; Sun, 27 Sep 2015 08:35:06 -0400 (EDT) +Received: by igbni9 with SMTP id ni9so34609999igb.0 + for <obnam-dev@obnam.org>; Sun, 27 Sep 2015 05:35:05 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.50.79.129 with SMTP id j1mr10122935igx.63.1443357305745; + Sun, 27 Sep 2015 05:35:05 -0700 (PDT) +Received: by 10.107.183.65 with HTTP; Sun, 27 Sep 2015 05:35:05 -0700 (PDT) +Date: Sun, 27 Sep 2015 15:35:05 +0300 +Message-ID: <CAJQvAudeWCMhMvExSSP3whzC4TAnkeOqNU5gNSdYyGxEM9bcnQ@mail.gmail.com> +From: Henri Sivonen <hsivonen@hsivonen.fi> +To: obnam-dev@obnam.org +Content-Type: text/plain; charset=UTF-8 +X-Spam-Score: -2.1 +X-Spam-Score-int: -20 +X-Spam-Bar: -- +X-Scanned-By: pepperfish.net, Sun, 27 Sep 2015 13:35:19 +0100 +X-Spam-Report: Content analysis details: (-2.1 points) + pts rule name description + ---- ---------------------- -------------------------------------------------- + -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low + trust [64.68.201.169 listed in list.dnswl.org] + 0.5 PPF_RECEIVED_HTTP Received header mentions http + -0.0 SPF_PASS SPF: sender matches SPF record + -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% + [score: 0.0000] +X-ACL-Warn: message may be spam +X-Scan-Signature: 0b3defc877126cf9a9969fd77535823e +Subject: Unlocking the repo from the VFS layer +X-BeenThere: obnam-dev@obnam.org +X-Mailman-Version: 2.1.5 +Precedence: list +List-Id: Obnam development discussions <obnam-dev-obnam.org> +List-Unsubscribe: <http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org>, + <mailto:obnam-dev-request@obnam.org?subject=unsubscribe> +List-Archive: <http://listmaster.pepperfish.net/pipermail/obnam-dev-obnam.org> +List-Post: <mailto:obnam-dev@obnam.org> +List-Help: <mailto:obnam-dev-request@obnam.org?subject=help> +List-Subscribe: <http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org>, + <mailto:obnam-dev-request@obnam.org?subject=subscribe> +Sender: obnam-dev-bounces@obnam.org +Errors-To: obnam-dev-bounces@obnam.org + +The unreliability of the connection between my local computer running +obnam and the remote SFTP server that I'm using for backup storage is +interfering with my use of obnam to the point that I'm not doing +regular backups. + +To address this, I'm trying to patch obnam to automatically reconnect +when the SFTP layer raises an exception. + +When the previous connection dies, a lock is typically left on the +server. This means that after reconnecting, the code should also +unlock the repo. (Obviously, unconditionally unlocking defeats the +whole point of having locks in the first place. Right now, I'm trying +to get to a point where I have something that works with a single +client. To do things properly, the client should store some +randomly-generated bits in the lock file and also keep the bits in +RAM. Then upon reconnecting, if the lock file contains the same bits +that the program still has in RAM, silent unlocking is safe.) + +Looking at the code for force_lock_plugin.py, it seems that just +calling that code from the VFS layer isn't safe, since on the VFS +layer, the repo is already open from the point of view of the repo +management code but force_lock_plugin.py opens and closes the repo. + +Any advice on what I should do where my current patch says "TODO: Need +to unlock the repo here."? I.e. how should I go about unlocking the +repo from within the VFS layer when the repo layer doesn't know that +the connection dropped? + +https://github.com/hsivonen/obnam/commit/358417c1891f28b869d4700bfa6feac88f79b78b#diff-0461b95928d689323962ad6b23dd4a09R59 + +(Aside: Is it intentional that some files have a GPLv2-or-later +license header instead of a GPLv3-or-later license header?) + +-- +Henri Sivonen +hsivonen@hsivonen.fi +https://hsivonen.fi/ + +_______________________________________________ +obnam-dev mailing list +obnam-dev@obnam.org +http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-dev-obnam.org |