Support git-annex type storage of attachments

[fpiper]

Since the changes to support Bibdesk org-roam-bibtex does not work nicely with git-annex anymore. Opening attached pdfs leaves one with the relevant pdf, but – due to completely following symlinks – opens it in a location from which one can neither easily navigate to other relevant pdfs nor gives the opened pdf a relevant file-/buffer-name.

This is a result of how files are organized in git-annex, which results in one directory containing symlinks to the actual pdf files. Notably the links have a meaningful name (e.g. author20_papertitle.pdf) and directory (e.g. ~/Lit), but the symlink targets have auto-generated hash-based names (e.g. SHA256E-s14843[…]37d6e17.pdf) and are stored in individual and meaningless subdirectories (e.g. ~/Lit/.git/annex/[…]/SHA256E-[…]/SHA256E-[…].pdf).

Proposed Solution Make the file-truename call in orb-open-attached-file optional. I am not too informed on how org-roam-bibtex handles attachments and for what parts the file-truename is necessary, but maybe there could be a check based on other existing config variables or introduce a new one.

[myshevchuk]

Hi @fpiper,

thank you for reporting it. Symlinks have often caused mess for Org-roam and ORB. In this particular case, true file names were necessary to correctly work with Org-noter, I believe. If files were opened as symlinked file names, then the Org-noter workflow was suffering from a problem similar to yours as far as I remember.

In any case, did you try your solution, does it work for you? If yes, I'll provide an appropriate switch. I currently don't have enough time to test it because I don't use git-annex.

[fpiper]

Yes, for testing I just removed the file-truename call in orb-open-attached-file and it opens the pdf, but does not resolve the symlink. Therefore opening all files in the intended location.

Thanks a lot!

[myshevchuk]

@fpiper done!