Late to the party, but I've just been wrestling with this myself. Just to be clear -- because the various edits and unedits to your question were a bit confusing -- I think what you were asking was, using well-established and widely-understood unix terminology:
Is there a way to link to a file by specifying only its basename;
i.e. without having to also provide its dirname.
Is there a way to link to file
blob.txt; i.e. without having to also provide,
If that is what you were asking, then you can achieve a form of that by using Org's attachment: style of link. So where, in your question, you had:
you'd actually have:
Then when you did
C-c C-o ('
org-open-at-point') over that, Org would Just Figure Out what the "path" was to get to blob.txt.
The mechanism is that of
org-attach, and specifically,
org-attach using the ID method (as opposed to the DIR method). Using
org-attach like that results in the following:
- An ID property is created for the heading from which you want to link to your file
- Then, based on that ID, an attachment directory is created
- And then your file -- or a copy of, or link to, it -- is placed into that newly-created attachment directory
- Finally, an attachment:-style link can be added to variable
org-stored-links-p. You can then use
org-insert-link, to insert something like
[[attachment:blob.txt][blob.txt]] into the body of the heading in which you are working.
That's just a summary of how it works. It's slightly more complex in that there are a few other things that need to be in place to get it to work just as I've described. On the other hand, in practice it can be even simpler than I've described in that you don't even need step #4 if you don't want it. Org can figure out where the attached file is without that
[[attachment:blob.txt]] link at all. It can actually get to and open your "attached" file just from the heading itself.
Now, cool and funky though all that is, the (potential) problem, given your specific question, is that although with this mechanism you get to leave it to Org to figure out where the linked file is located, the intention is that you also leave it to Org to decide where that location is in the first place. So you can't easily (although I suspect it's possible) do exactly what you have in your example, and just link to something like:
../../blob.txt. Instead, you'd find that you were linking to something like:
./data/20/221108T085858.791822/blob.txt. Of course it is usually the case that, as discussed, we wouldn't really care about that scary-looking filename, because we would be referring to that file as, at most, something like
[[attachment:blob.txt]] or, even better, not at all and just relying instead on the implicit linkage between your file and the Org heading in question. But that is usually the case. Whether it applies in your specific situation, I can't tell.