From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id KSybH/oQfGadwQAA62LTzQ:P1 (envelope-from ) for ; Wed, 26 Jun 2024 13:00:42 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id KSybH/oQfGadwQAA62LTzQ (envelope-from ) for ; Wed, 26 Jun 2024 15:00:42 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Gl6Vptss; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1719406842; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=cV/fCmWySuOwDesBGpeAHfR/9EFhvo7EL1TLInuEBoY=; b=SNDA2Y82LjaKc895ui+r0rDc7oHrdD1sI+v7RjzqTFnk3dLBcqXvRewFLPax4r2fbIFb5m LzJL9MONiJAxbP8TntovMrklzj/TtNn56HlPx5+is3GxPiK44eSqJALXA/aBqELA0hMeyj btchITICUFUOSZz7Fm+AjolQVbTfW0zG8LfK3YguxKAcO2widivBCl9Z6I9ooC/UKD31uV S7scKYSLIap4ThlWR/cH7KirhvR8tP7i9g0+gjrSscpBxI/xsXzC7q5NnU1rt855EEJhca 9YK7ovVWhz49Lae624AeQ679FcFx2Boj5+9vN8GtUSsQrwribk6yB0zqZkoDYg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Gl6Vptss; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1719406842; a=rsa-sha256; cv=none; b=qYYQRnqtpMSf+Eh85jq/0/1yUuXCd7PQ5psF0INakp08SIW1n6L0bjvyGT1XYxe31p5afB QztLiyS3H/PtYDFrb6crrVgmn9LtxcbsBn9S7W4YkHhZBD9VIP0k9+VS6eyJasJST8wNQG dRJI3LtAXmQNdBv3Wkk/wSljdTkVLny3eGx4uYTY8mFdkTHrveJhuCJ8hzYHp8kjb9nXZM qHalaefPihYCO1UQHHZZmXLiOxVyLj4hdnmXMGxm/w0vPWOgGtyGou/lWGgy3on4D6zuJr 4oxhbHflDeSW25R6mgg27rw5NyiIduBgeE7hDff4sCON0n+J/8R3XUcd3cr/4Q== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D1DB774A21 for ; Wed, 26 Jun 2024 15:00:41 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sMSFX-0008UX-LG; Wed, 26 Jun 2024 08:59:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sMSFW-0008U8-1O for emacs-orgmode@gnu.org; Wed, 26 Jun 2024 08:59:46 -0400 Received: from mail-vk1-xa34.google.com ([2607:f8b0:4864:20::a34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sMSFU-0003X2-DN; Wed, 26 Jun 2024 08:59:45 -0400 Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-4e4efbc3218so2688859e0c.0; Wed, 26 Jun 2024 05:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719406781; x=1720011581; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cV/fCmWySuOwDesBGpeAHfR/9EFhvo7EL1TLInuEBoY=; b=Gl6VptssaVTy9390P5UX5V4DV6UpLulbRNUGZm0KZwFU8i362cUxitO2yFOz1B6Rmf vugEEeTsmIt0NnzW5QI5HxxIEsDUhL87oeubz8tNpOFtXRKawc6FnBLKPZbn2F9F2cDX FXIdgaz2GISj048oN9hXKHLVydZEU37/ZuX+a0fMCHH42buvpxs5Uw4AzH7FjLvdTwbk HVytRFZsIBVk2cfRcn5eudQGTzSY2MukeWVoOiSKNBNRi0s0+R5Cq9lIJnaNncbvwhSO yxTPXldv7RuX2vXE6UE8pA/K3tVia94sD03nwSKXuIuhu363h3Fre+AeuK1V5Kwgsh2+ VUKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719406781; x=1720011581; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cV/fCmWySuOwDesBGpeAHfR/9EFhvo7EL1TLInuEBoY=; b=PW3ONbTKp1GB/XKOpDWsboXS7Qb03L23cnbFmPG+5RWAwfMjSDeD8RhMsbaFNPAN5e GpFdOIrlY6W/dftfIVhM9V5mvCnVSj0/NfVaQTkXWw2RUFEEgO46Hu5jhXM988dIxwml D1LqwCdNr52HkXDURsK43aMBKztuKDXmYIy5ZY74ZU5whZ4kMvtOA9FK7RSgEG6i25OF C1P43xXftC4TyLLzsfrErti7Zf4LQwjZY3mEEi3IfGUpxJbCfBY4aUW49SAX11gKk9pr qWR8W0rUXI8cZYhyHUTf3OXSV7YFHlKI7LUA6UEhMPH1AOw2eBBDkWecrdnTaWV3bjay z/7A== X-Forwarded-Encrypted: i=1; AJvYcCVFajSKI/Jrzu0JqdcB8Vmb1UO3vPOJwKOXEquSXYHeh8y5IPPKpRzma8c+EUkrt074uTskZU4ZUBlnAG0FYTQzpMiLdM8= X-Gm-Message-State: AOJu0YxwQCrai7r5rK4aeCGFVGLfjDLp+tCxiLwGTX4jrE83WIxchvUy J7rURHHpytRmqt7absDvLl79v4q5fjwb3xx4BaRX7WViqf5MXbG4m2UX9CLSDKga0yFe7+pzPPK pM2EM/gvTCXnQLSd6e+KtHKE82ps= X-Google-Smtp-Source: AGHT+IHu8TXs56u6LYJax6O1SCXzRW0wTqEklLbAgc4xDO353zTlpUqIhjcjfGs4DkeD99phymmLfT3qDAdJ0k2WfNE= X-Received: by 2002:a05:6122:16a5:b0:4ec:f4a2:69fc with SMTP id 71dfb90a1353d-4ef6d827d01mr9133645e0c.7.1719406781381; Wed, 26 Jun 2024 05:59:41 -0700 (PDT) MIME-Version: 1.0 References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.fsf@localhost> <87o781t676.fsf@localhost> <874j9qs0wh.fsf@localhost> <87ed8mtyp0.fsf@localhost> In-Reply-To: <87ed8mtyp0.fsf@localhost> From: Daniel Clemente Date: Wed, 26 Jun 2024 12:59:12 +0000 Message-ID: Subject: Re: Please document the caching and its user options To: Ihor Radchenko Cc: Eli Zaretskii , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::a34; envelope-from=n142857@gmail.com; helo=mail-vk1-xa34.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -9.71 X-Migadu-Queue-Id: D1DB774A21 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -9.71 X-TUID: d6pPAhM34INZ > > A user has somefile.org which contains some headers marked with the > > "crypt" tag. Only those headers are encrypted. The org-element cache > > may now cache the whole file, including the encrypted headers (this is > > ok). Now the user temporarily decrypts the encrypted header, works on > > it some time (including closing the file and opening it again) then > > encrypts the section again. During the time that the header was > > unencrypted, the org-element cache was storing information about > > unencrypted data in ~/.cache/org-persist, which could even be a remote > > server (NFS, SMB etc), not as private as the org file itself. > Nope. Storing to disk only happens when you kill the buffer and before > exiting Emacs. At that point, org-crypt must take care about > re-encrypting everything. Sometimes org-crypt fails to reencrypt the data. E.g. if Emacs crashes, or if you fail to type the same password twice, or of course if you don't use (org-crypt-use-before-save-magic), etc. At the end of the day when I do "git diff" + "git commit" sometimes I realize there's unencrypted data and then I have to reencrypt it. In the meantime I might have killed and reopened the buffer, thus updating the file cache. That may be a problem by org-encrypt and something to document in org-crypt itself. The point is that users of org-encrypt should take extra precautions when enabling org-element-cache-persistent. Like: not closing buffers while the sections are unencrypted. > Multiple Emacs instances are handled correctly. I do not see much > point documenting that things are working as expected. Ok, thanks, it's good to read this guarantee here. I'm used to org-element cache inconsistency errors, so I didn't know the state of things. I agree it doesn't need to be in the docstring. If there's some chapter about caches in the manual (which is one of the topics in the original post of this thread) it can describe these minor things. But the major ones like what does it do and to turn it on/off are more interesting.