Shouldn't org-attach-store-link-p result in links to the actual attachment?

TeeMcBee · 2022-10-23 17:18

# TL;DR The `:file` link created by `org-attach` when `org-attach-store-link-p` is non-nil should be to the attachment, not to the original. In fact the link is to the original, not to the attachment. I believe this is a bug. org-version is 9.6-pre. # DETAILS I've noticed some unexpected behavior in terms of the link that `org-attach` creates and places in `org-stored-links` when `org-attach-store-link-p` is non-nil. I'm seeing it when the method of attachment is *move*, *copy*, or *symlink,* either via `org-attach-method`, or when chosen directly when running `C-c C-a`. (I haven't tested any of the others. *Although now see my ADDENDUM at the bottom of this post*). The issue concerns the target of the created link. My expectation is that the target of such a link should point to the actual attachment itself. By that I mean, the target should be the path to the file or link in its place ***in the attachment directory***. It should NOT be the path to the original file ***in its original location***. However, the latter is what I'm seeing. I believe that is a bug. Couple of questions then: 1. **Does the above make sense, and do you agree it seems to be a bug?** 2. **Do the org devs use any kind of issue tracking system that is visible to the rest of us, and if so where is it?** My instinct would be to check that first in case this is already a known issue. I have already had a quick look at the emacs-orgmode archive, to which I have recently subscribed, but nothing obvious jumps out at me. And an issue tracker would be more definitive. # ADDITIONAL INFO At first I thought I might just be mis-interpreting the docs, a strict reading of which might be taken to mean that the current behavior is correct. Specifically, the doc for `org-attach-store-link-p` says (bold emphasis mine): *"Non-nil means store a link to a file* ***when attaching*** *it."* Notably, it doesn't say \*"...\****after*** ***attaching*** *it".* So sure, if someone was in court and facing the death penalty for the crime of linking to the original path, then they might be able to argue their way to an acquittal. But I don't *think* that linking to the original was ever the intention. And even if it was, I'd say it shouldn't have been. But what convinces me this is clearly a bug in function and not (merely) documentation is that it happens even when the method of attachment is *move*. In that case, obviously the original file is simply no longer in its original location at all. However, the target of the link created and inserted into `org-stored-links` is still the file on its original path. As a result, if the user inserts that link into the org file using `org-insert-link` and then attempts to follow it using `C-c C-o` or similar, they end up with a new buffer intended to create a new file at the location of the now-no-longer-there original. # ADDENDUM I just tested what happens if I run `C-c C-a u`, that is, attach a file downloaded from a URL. For the URL I gave "[https://orgmode.org/manual/Summary.html](https://orgmode.org/manual/Summary.html)" which I happened to have open in my browser. The result was that the file was successfully downloaded and placed in the required directory, but when I ran `C-c C-l` (`org-insert-link`) to grab the link created and placed in org-stored-links I found that it was as follows: Summary.html <file:[https://orgmode.org/manual/Summary.html](https://orgmode.org/manual/Summary.html)\> That was then placed into my org file as follows: `[[file:https:/orgmode.org/manual/Summary.html][Summary.html]]` which is clearly wrong. thanks!

yantar92 · 2022-10-24 04:40

> Does the above make sense, and do you agree it seems to be a bug? Yes. Fixed. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=48b237d9e21a4edf528d4bd1ed99d1f3757e4931 > Do the org devs use any kind of issue tracking system that is visible to the rest of us, and if so where is it? Yes. updates.orgmode.org. But it is only for confirmed bugs. Searching email archive is more reliable. Also, see https://orgmode.org/worg/org-contribute.html#org89a48b5

TeeMcBee · 2022-10-24 19:46

Excellent. I just pulled down 9.6-pre0.20221024.43732 and I can confirm the problem is fixed. Thanks for such a fast response! One final (ha!) question about this stuff. I see that another way of linking to attached files is using the "attachment:" link type. So the following is a valid link: \[\[attachment:attached-file.pdf\]\[attached-file.pdf\]\] However, while that form is nice and succinct, as far as I can see it is something you have to enter manually. In particular, it does not appear to be used for links stored in `org-stored-links` by `org-attach` (i.e. in response to `org-attach-store-link-p` being non-nil). Instead, the link type always seem to be "file:", which means that in the worst case (i.e. ID method, and `org-attach-dir-relative` nil) the link will look something like this: \[\[file:/abs/path/to/my/orgdir/<DIR>/data/F5/56B-4E3C-B0A9-6A6D5318DF5E/attached-file.pdf\]\[attached-file.pdf\]\] Do you know if the non-use of the "attachment:" link type was intentional? Would it be worth considering making it at least an option -- perhaps by expanding the values permitted for `org-attach-store-link-p`? thx.

yantar92 · 2022-10-25 00:05

Just use `attached` value for `org-attach-store-link-p`

TeeMcBee · 2022-10-25 02:21

Ah. So it was there all along. I was focusing on the `C-h v` description I got for `org-attach-store-link-p` which doesn't actually say what the non-nil options are. I'd been assuming there was only one: `t`. I now see, in at very least the descriptions in the customization options for that variable, that there are not *one* but *three* non-nil options, Duh! But as a result, I now suspect my entire "bug" report was wrong, or at least only partially right. My report incorrectly assumed that setting variable `org-attach-store-link-p` to `t` and setting it to `'file` (even though at the time I didn't even know that was an option) were one and the same thing. But they are not; at least, not according to the customization options for `org-attach-store-link-p`. According to that customization information here are EXPECTED and then ACTUAL link types and targets for the three non-nil values of `org-attach-store-link-p`: `t`, `'file`, and `'attachment`. Notice the mismatch for LINK TARGET for when that variable is set to `t` : **EXPECTED** |org-attach-store-link-p|LINK TYPE|LINK TARGET| |-:|:-:|:-:| |**t**|file|\>> original location *<<*| |**'file**|file|attach-dir| |**'attachment**|attachment|attach-dir| **ACTUAL** |org-attach-store-link-p|LINK TYPE|LINK TARGET| |-:|:-:|:-:| |**t**|file|\>> attach-dir *<<*| |**'file**|file|attach-dir| |**'attachment**|attachment|attach-dir| My problem now is, I'm not actually sure *what* the EXPECTED values should be for the various options for `org-attach-store-link-p`. Here are some specific concerns: 1. Since most users (I'd guess) would want the link target by default to point to the attach-dir, and not the original location, then does it make sense for a value of t to mean the latter? For backwards compatibility purposes it is probably impossible to change the link target meaning of t, but I wonder if it would have been better for it to point to the attach-dir. 2. If the meaning of a value of t remains as customization currently describes it -- i.e. the link target should point to the *original* location -- what exactly does that mean if the user chooses to attach a file using the *move* method, or from a URL by downloading? In both cases it just doesn't seem to make sense for the target to point to the original file location. 3. As it stands right now -- i.e. after your fix u/yantar92 \-- I think that when it comes to a value of `t` for `org-attach-store-link-p`, either the customization descriptions are wrong (they say the link target will be the *original location*), or the behavior is wrong (the link target actually ends up being the *attach-dir*). \--