Re: [PATCH v3] Re: [BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)]

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> 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