1 Return-Path: <amdragon@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 CC399431FD0
\r
6 for <notmuch@notmuchmail.org>; Tue, 21 Jun 2011 09:01:18 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
\r
12 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,
\r
13 RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id cuya1VQ-rRCh for <notmuch@notmuchmail.org>;
\r
17 Tue, 21 Jun 2011 09:01:18 -0700 (PDT)
\r
18 Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com
\r
19 [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 4EF50431FB6
\r
22 for <notmuch@notmuchmail.org>; Tue, 21 Jun 2011 09:01:18 -0700 (PDT)
\r
23 Received: by qyk9 with SMTP id 9so2045036qyk.5
\r
24 for <notmuch@notmuchmail.org>; Tue, 21 Jun 2011 09:01:17 -0700 (PDT)
\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
\r
26 h=domainkey-signature:mime-version:sender:in-reply-to:references:date
\r
27 :x-google-sender-auth:message-id:subject:from:to:content-type
\r
28 :content-transfer-encoding;
\r
29 bh=DEPv2cG8I+YymjPZ/Io4rESDFYFxU1w9gZCIcatLDp4=;
\r
30 b=hXpZuSPlqASJQZdeQXvb8whbPn+ce20EeYgEtQf3B52m00K3BM6cO7WKrXjGu7riwk
\r
31 s7sKz78Xo1pXjz1uSncTf+IKU63pcmOANIIxaFfsKTOe9+HiOxH5zThAm47x7zPxCPSW
\r
32 3Gwwg42tcr8+JkORNjr4S2Jdmdwrdn8BPjVg4=
\r
33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
\r
34 h=mime-version:sender:in-reply-to:references:date
\r
35 :x-google-sender-auth:message-id:subject:from:to:content-type
\r
36 :content-transfer-encoding;
\r
37 b=AyfDRys8ZmzsRqS3uDjo63JTzVM8nY7yCwjRyktdUD7JFW2LUScg4r0c5SJIcUxqK9
\r
38 oE5bXqwzjZ6iYbRGb9ynfVv/NjyeGQfS5iFb9fxNtOYOlT/9NytO49y1LFKgNUvXGmH4
\r
39 /bvGDTs/Q4o9UlEmTkq81xY9Y76V+y2zCj3hM=
\r
41 Received: by 10.229.18.67 with SMTP id v3mr5268842qca.100.1308672077488; Tue,
\r
42 21 Jun 2011 09:01:17 -0700 (PDT)
\r
43 Sender: amdragon@gmail.com
\r
44 Received: by 10.229.32.197 with HTTP; Tue, 21 Jun 2011 09:01:17 -0700 (PDT)
\r
45 In-Reply-To: <4E0091AE.5070609@fifthhorseman.net>
\r
46 References: <20110610073208.GA74787@codecafe.com>
\r
47 <4E0091AE.5070609@fifthhorseman.net>
\r
48 Date: Tue, 21 Jun 2011 12:01:17 -0400
\r
49 X-Google-Sender-Auth: s8hXmck4YsOkSc_igawn0-ls_c8
\r
50 Message-ID: <BANLkTik_o6d03g7Jsy-sUbjCp9HR7Q=rkw@mail.gmail.com>
\r
51 Subject: Re: [PATCH] notmuch-new.c infinite recursion symlink bug
\r
52 From: Austin Clements <amdragon@mit.edu>
\r
53 To: notmuch <notmuch@notmuchmail.org>
\r
54 Content-Type: text/plain; charset=ISO-8859-1
\r
55 Content-Transfer-Encoding: quoted-printable
\r
56 X-BeenThere: notmuch@notmuchmail.org
\r
57 X-Mailman-Version: 2.1.13
\r
59 List-Id: "Use and development of the notmuch mail system."
\r
60 <notmuch.notmuchmail.org>
\r
61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
62 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
64 List-Post: <mailto:notmuch@notmuchmail.org>
\r
65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
67 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
68 X-List-Received-Date: Tue, 21 Jun 2011 16:01:18 -0000
\r
70 On Tue, Jun 21, 2011 at 8:42 AM, Daniel Kahn Gillmor
\r
71 <dkg@fifthhorseman.net> wrote:
\r
72 > My point is: there are lots of ways to get infinite recursions via
\r
73 > symlinks; =A0hard-coding a check for one specific way seems like a
\r
74 > sub-optimal approach, because it leaves the other paths still present,
\r
75 > and introduces an unexpected/surprising asymmetry.
\r
77 > I'm not sure what the specific right way is to solve the problem you
\r
78 > identified, though.
\r
80 A simple solution to this problem would be to record the inode numbers
\r
81 of each visited directory, probably in a hash table in
\r
82 add_files_state_t. At the beginning of add_files_recursive, right
\r
83 after it stat's the directory, check if st.st_ino is in this hash
\r
84 table; if it is, return immediately, otherwise add it to the hash
\r
85 table and proceed as usual.
\r
87 Alternatively, because of folder search, it might be better to keep a
\r
88 stack of inode numbers to eliminate loops while retaining notmuch's
\r
89 current approach of repeatedly indexing mail that's symlinked in
\r