From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UIazEcE292IrFAEAbAwnHQ (envelope-from ) for ; Sat, 13 Aug 2022 07:29:37 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id GH6oEcE292IEUQEAauVa8A (envelope-from ) for ; Sat, 13 Aug 2022 07:29:37 +0200 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 E376D26332 for ; Sat, 13 Aug 2022 07:29:36 +0200 (CEST) Received: from localhost ([::1]:36842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMjiJ-0007lr-PS for larch@yhetil.org; Sat, 13 Aug 2022 01:29:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMjhT-0007lj-Ff for emacs-orgmode@gnu.org; Sat, 13 Aug 2022 01:28:43 -0400 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:46624) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMjhR-0003CU-Iq for emacs-orgmode@gnu.org; Sat, 13 Aug 2022 01:28:43 -0400 Received: by mail-pf1-x42e.google.com with SMTP id 130so2587758pfv.13 for ; Fri, 12 Aug 2022 22:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=QgJb+d8iKzX6omlBDdXQFzE0kT8Ev3OaZmM+dxjd4CM=; b=GJlRR7g/gpkju4NKc7FVlb3YY5Zt9lfQRw8bqPNdmbeaa1oCOrbtAG/nNkEvjb/U1m ULJkeid2JZMEaXenK/Vr+wOmXH3KVrV4lsngamtvDTXL8KauFU8fm2ov4D7gZN9JMkF6 c6GPIxxGC1MAwZgOV0kcP7lF4a9/cn/0m0QARRQD5JWsSZTmd6jCC4G1Pas7PjKVH178 rCCCjiKZTDH7nveQTDldp8MW9XEkWL0Yu2wMYgoFzRhfd5Fz0i12qJwPA6yhzsSSGTvo RB+R6d+RkmkuHKoeCpL9c9EdcJxcuLaaJkh1KBYb9G9/ZS30rKatt8vUYKj1FFrCGoZ6 mdww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=QgJb+d8iKzX6omlBDdXQFzE0kT8Ev3OaZmM+dxjd4CM=; b=WvOrlxDqnUs4M8cy7kxcg7ujr1dSzqxC87P/UGggRIT3aXLIuBs6RBnIqbYuz5Mrw7 ZGoSLGnUaJq75B6LDHyUosK0LvJwqCnklfv30K0sNFecC5uuVhAJElLBn470Ogydjrge /Vf7XLcQB7eZyCkelyo9hDmD6IMLCGkX1sSjCDAjyT1zxl85v+WUX0HnsjItKWwPge5B 3k0HqY6NNiOJD/6NC972VtX5+QDeyKjqyCSZQZfcbtjKaM7aiXS5zRDN7ED36V9Lnrmd ORJo9xZTcTfkXGZl3B9ZYBj2ZIeo2DruWWZ4FN79U5RHDYjuFhnpkuEa2Xf9rrmI0IwC 91VA== X-Gm-Message-State: ACgBeo0i8Hf5iEbPBlrNhddFFqXmrwd2GmWstHlISB4abYB7waeudg5i dCecXCAU7GJ+Jtz8BETaDOY= X-Google-Smtp-Source: AA6agR5GyGgrJwVzbvuoEdqJqUB6x5vaYiiwIC6NlP5a2EUVsk18/OL3ev4Z58OPr6fBjxkAzkulmg== X-Received: by 2002:a62:52c3:0:b0:52d:c062:27d2 with SMTP id g186-20020a6252c3000000b0052dc06227d2mr7170730pfb.53.1660368520210; Fri, 12 Aug 2022 22:28:40 -0700 (PDT) Received: from localhost ([2409:8a70:2bf:80b0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id p67-20020a62d046000000b0052ddaffbcc1sm2588504pfg.30.2022.08.12.22.28.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 22:28:39 -0700 (PDT) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org, Janek F Subject: Re: [PATCH v3] Re: [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)] In-Reply-To: <35cbf452-c3ed-d97f-db96-dcae57463eff@gmail.com> References: <87k084v1wa.fsf@localhost> <871qtxhsm6.fsf@localhost> <87a68ce32u.fsf@localhost> <871qtodygs.fsf@localhost> <87v8qz9zui.fsf@localhost> <35cbf452-c3ed-d97f-db96-dcae57463eff@gmail.com> Date: Sat, 13 Aug 2022 13:29:41 +0800 Message-ID: <87wnbc7ltm.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=yantar92@gmail.com; helo=mail-pf1-x42e.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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, T_SCC_BODY_TEXT_LINE=-0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660368577; 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=QgJb+d8iKzX6omlBDdXQFzE0kT8Ev3OaZmM+dxjd4CM=; b=M1/j41MufU7LNke0Ccb8U3y7VC5I3XWUi8mU4L/79CCO2W2o0Se07xG4njpMdRFrf9iunl Vovs1cLQFbs0IhOjZRg2bGmrKO36h7ZqeruOZf/QP/eWRfvQsn3OiL2qun+ejg9cO3dAt9 kwqK7/vgYsLyvSD+hgNS5u3BHJxuREngYY+T94frSJt3N4azSDMtTynhs/gwOJjV4n+L3y iYSoLkfzbNCq5/g+NOaToTOC6AZmf4ckcbKtRWFLONUBPvqG7mEgTBhpoICkz5PjmxIUs1 uL192BGzWlE32bskGWiaoRcuR0dbTzxiTWRVjREG+ex+3v+xqslexQAZSwZD/A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660368577; a=rsa-sha256; cv=none; b=AVH9jHLxKDaqvmX6NPnSFp+5ljgiKbBtTWQOeMdmBobUVEgHacjSo3JhJLhGMCECRxSdUx OVjhHDVOQ+ndDAoHdEqhiAYkGjZ6lDlmT55eH8HWb2QMN3AwaK0BnDpZHpAAHVCONtHXd8 pxBs4m5uTGSItXcY2DoYYvuJrgMKcGOBKhG/Npc1ZUwVsxKxDIMDLnmG5AOBl8SXq+iEOp ty5w4S7N9W6C3TC8yHLhZNlRsV+0OiacmI2//uZChWNP2clW5B469UkQCkx8BeDJ9MPAl0 6GlalU+AGrBfi6TCiBW3PrRYzhWVkAEJwQUrJ6AwgsN/6sSkUMIv/UqDPdrOog== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="GJlRR7g/"; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Spam-Score: -7.36 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="GJlRR7g/"; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Queue-Id: E376D26332 X-Spam-Score: -7.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: 2h49HyYEjb1w Max Nikulin writes: > was a really bad one. It leads to a separate directory for each short > ID. However I still believe that the purpose of > `org-attach-id-ts-folder-format' is avoid concentration of huge number > of file in a single directory. Distribution of attachments over > subdirectories is not perfectly even but it still works reasonably well > for long-lasting projects while IDs follow assumed format and month is > included into directory names. This is only true for uuid-style. Also, this is likely not the problem we need to worry about. To be a problem, the number of attach dirs should be really large, which is only relevant when thousands of attach dirs are cramped into a single parent directory. Thousands of attach dirs would probably correspond to tens of thousands of headings, which is not something we commonly have and, honestly, Org will have much more serious issues when the number of headings is that large. If someone ends up complaining about too many attach dirs, we can always ask to adjust the ID naming scheme. The previous paragraph appears to be consistent with > Back to the original problem. First of all, I believe that if a user > decided to use non-standard IDs then it is their responsibility to > customize `org-attach-id-to-path-function-list' and to provide a > function that implements alternative layout of attachment files. > Depending on expected amount, they may be put into single directory, > spread using some hash function, or accordingly to project structure. So > today I am against default fallback directories especially in > `org-attach-id-ts-folder-format'. --- > I believe that interaction between `org-attach-dir-from-id' and members > of `org-attach-id-to-path-function-list' could be improved. If a too > short ID is passed to `org-attach-id-uuid-folder-format', > `org-attach-id-ts-folder-format', or a user-defined function, they may > return nil and `org-attach-dir-from-id' should try next element from the > list. If nothing succeeds then a user error should be signaled demanding > to implement a strategy to properly deal with peculiar IDs. I do not think that it is a good idea. We currently promise to use the first function in the list to generate the IDs. Other functions are mostly a fallback to catch the existing attach dirs created in the past using different ID scheme. I guess that one option could be demanding a non-nil return value when generating a new attach dir (without TRY-ALL argument) and wrapping things into (ignore-errors ...) otherwise. > There should be no problem to put single character IDs into a common > directory (UUID case), but there are enough variants for 5 characters > long names to create delayed performance problem. The worst case is when > a user decides to use some common prefix, e.g. "id-" before UUID and all > files go to the same directory. On the other hand I do not think that > code should detect such cases. We should not worry about this. It will be the user responsibility to create the relevant custom function. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92