From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id +Cw5LscV9WJihwAAbAwnHQ (envelope-from ) for ; Thu, 11 Aug 2022 16:44:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 8AJiLccV9WI1YAEAG6o9tA (envelope-from ) for ; Thu, 11 Aug 2022 16:44:23 +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 697C62E3 for ; Thu, 11 Aug 2022 16:44:23 +0200 (CEST) Received: from localhost ([::1]:52544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oM9Q5-0001Ya-NF for larch@yhetil.org; Thu, 11 Aug 2022 10:44:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33118) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oM9PG-0001XL-UN for emacs-orgmode@gnu.org; Thu, 11 Aug 2022 10:43:32 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:41887) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oM9PC-0000Vo-OJ for emacs-orgmode@gnu.org; Thu, 11 Aug 2022 10:43:29 -0400 Received: by mail-lf1-x132.google.com with SMTP id t1so25850978lft.8 for ; Thu, 11 Aug 2022 07:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:cc:to:references :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=7prPKqigkNGyT6xk1E5dUhaSMmh2PRI4ChtCNcgM7JQ=; b=JB1SbJFY2FYnNzHKPIkVBIOnMczOYvg1pI19LH81WsYTNxkvinyHXOQZs64SpWNZbG Wz0deunQBqQt2AeBu2pIRnheFTCATxnP2YBxGH9zuNypiSn/6AxR1qjpPiCEmHeAwenM BPtNd+3VImz3dpdV0c9OI0I2eSxJhJQgELgqOocM7F4FuB63WowD7Jv17koPEMqZRdT4 VeuHUa0A2kR59kR8OiKKTkKkIALrQ7JmbBqa56oR+W/1BipoRYTRv7V860C5qpFPP1Tc eTGfMY6wI8jmYKBrMDJ+MXQ5Fw7lu8xqTDeItCVebB3KVb0VNK9i/zVtwMnSz9ybC9tw hu3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:cc:to:references :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=7prPKqigkNGyT6xk1E5dUhaSMmh2PRI4ChtCNcgM7JQ=; b=zldxcrrbK6ncfkjjXl6w+skHV3fhUG/zz21Lat3FnhAK1/xoONI9J0SlaSgQIxJ104 u2fZVFhOfYLeFPGxn1t2ED0CdjaO82/Z5RLr9sL21GXqR7wfeJPNEJcRRWU1u5u6EyBj PDXpWOXdthCdbyw0FidUER2fDFojuXSTf93bxfAXDoLj6S0l4G56Dl10FSxehzisFhFK yWult2viJSDQUZHwd3SrRaPLdkxNTlRaf3fBtTpG8VwYZVv8YkGT0JbssyE800OgoMlD /NfUnZ0ZJvyc8Ald/mgSs/oMG68S8gL7Oq9jLqbhQxbFPZorikwhqccwRuUkXLyEoloq A/fQ== X-Gm-Message-State: ACgBeo3SoLqv3cx0lxfXVv7QI0G/gZ7Cin71qJOHEFIl+YVYTMNkCxQ0 xn+wo96JwOPX1aiL8TW+qv2UYnpyGpU= X-Google-Smtp-Source: AA6agR6Xx+x4kLTLZiha/iPaQ8uUASEA6d8VtPPWMETMpfyFy+MFBVcEFWuLYNvQQDTOjtQCBh86UQ== X-Received: by 2002:a05:6512:3d04:b0:48a:f6cf:cf03 with SMTP id d4-20020a0565123d0400b0048af6cfcf03mr11491765lfv.539.1660229001409; Thu, 11 Aug 2022 07:43:21 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id o20-20020ac24e94000000b0048aa061c862sm732948lfr.1.2022.08.11.07.43.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Aug 2022 07:43:20 -0700 (PDT) Message-ID: <35cbf452-c3ed-d97f-db96-dcae57463eff@gmail.com> Date: Thu, 11 Aug 2022 21:43:18 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v3] Re: [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)] Content-Language: en-US References: <87k084v1wa.fsf@localhost> <871qtxhsm6.fsf@localhost> <87a68ce32u.fsf@localhost> <871qtodygs.fsf@localhost> <87v8qz9zui.fsf@localhost> To: emacs-orgmode@gnu.org Cc: Janek F From: Max Nikulin In-Reply-To: <87v8qz9zui.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=manikulin@gmail.com; helo=mail-lf1-x132.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, NICE_REPLY_A=-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=1660229063; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=7prPKqigkNGyT6xk1E5dUhaSMmh2PRI4ChtCNcgM7JQ=; b=C3AAKVcyJqxykoFC3G1024C7gY98zKWorqhHXo4ooTA20uAoVJkEp7a48O+qHiz//g5ng+ e3EbEhfAwu/xeOzfh/Cm93cQYHOb7iNpR6+Mehgl+sJtnlvpaH6xNrms9bKrQg3F3SBSxB 1IvTlvHNcXq0tBItc+fYEI5MzdRtAEfOYaP8joZoNAAoe18ncX6EswO5xkqqZMTL5RmBGQ /becwE8rFRT1wDe4Cp9be4118THxhJX4SdeEoq+MpZRqse57x/TfO3lqFKGeco+1vBp/VN qaAxE/QM7fZu0/82U3O/6yhjMRboPuqm1iB/yxGOSfq98qFOw5J4mhxRd9u70A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660229063; a=rsa-sha256; cv=none; b=BjFyDL5bZ+vgXt3o2pmKMuuap2iU1J7HMZCRabR9HXSGLQkC7qDmrS6OimrT12u3e+ihT3 T2mLIE2YCEUsEcCWq5FZ4MOZZnffHSsUUFyBLM7Xefh81y6qMFH8xx+4u428BFIZn5+zMI yGN6weBhv/63b5hDV6QSD6wD2zYw/Tc8bFqNKeUJhz5OzNck+vKk6fAyPrJ8FcttVdV458 m/+FqRvjw5ZGBd8QlsF3eOpkhU64TkmMdVk4EwsMEMtbvllxuTQdeQenAIF6jazCSJsYhh 14jTcBckaEsIj1csPSjLbakFt9BCOxnAcnidTjpS9Ja6W0YXV3X2sumqw5PAMw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=JB1SbJFY; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: 5.82 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=JB1SbJFY; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: 697C62E3 X-Spam-Score: 5.82 X-Migadu-Scanner: scn0.migadu.com X-TUID: 52QVXwS7I76k On 11/08/2022 11:19, Ihor Radchenko wrote: > Max Nikulin writes: > >>> I slightly dislike the "___xx" compared to "______" because it will >>> create a proliferation of top-level folders as opposed to cramping the >>> non-standard IDs into a single "______" folder. >> >> I believed that proliferation of folders is for purpose. Intermediate >> directories allows to avoid excessive number of files in single >> directory. ext4 with directory tree index usually is not the case, but >> other filesystems may have rather poor performance when too much files >> are stuffed into single folder. Some applications become really slow for >> huge directories. > > I was referring to TS style timestamp resolver here. It is designed to > group directories by creation time, not to distribute them homogeneously. My bad, I have realizes that my idea of mapping "x" -> "______x/x" "xy" -> "_____xy/xy" 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. 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. 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.