[BUG] Attachments not resolved correctly from symlinked Org files

[BUG] Attachments not resolved correctly from symlinked Org files

[Karthik Chikmagalur]

Attachment paths are not resolved correctly when the Org file is
symlinked elsewhere. This may or may not be a bug, but I think it's
undesired behavior:

1. Create an Org file somewhere, say ~/Desktop/test.org.

2. In test.org, create an attachment: `C-c C-a m' as a file.  Either the
   "copy" or "move" attachment method can be used.

3. Symlink test.org from elsewhere, say

/tmp/test.org -> ~/Desktop/test.org

4. In a fresh Emacs session, open /tmp/test.org and try to open the
attachment directory (`C-c C-a f').

Two things happen:

- An empty directory is created, like
  /tmp/data/48/2697ee-913c-4eee-b1fb-636416d3fb6b

- The original attachment can't be found, since it's actually in
  ~/Desktop/data/48/2697ee-913c-4eee-b1fb-636416d3fb6b

Tested with `emacs -q' with Org 9.6.23, and with commit
1ae978f940c0f88473f2232177c63a0de7fb7a1c from two weeks ago.

Karthik

Re: [BUG] Attachments not resolved correctly from symlinked Org files

[Ihor Radchenko]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

> Attachment paths are not resolved correctly when the Org file is
> symlinked elsewhere. This may or may not be a bug, but I think it's
> undesired behavior:
> ...
> 3. Symlink test.org from elsewhere, say
>
> /tmp/test.org -> ~/Desktop/test.org
> ...
> - An empty directory is created, like
>   /tmp/data/48/2697ee-913c-4eee-b1fb-636416d3fb6b
>
> - The original attachment can't be found, since it's actually in
>   ~/Desktop/data/48/2697ee-913c-4eee-b1fb-636416d3fb6b

I can see the problem.
But what would you expect to happen if there was no attachment in the
original directory? Should the attachment be created relative to the
original file? To the symlink?

-- 
Ihor Radchenko // yantar92,
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>

Re: [BUG] Attachments not resolved correctly from symlinked Org files

[Karthik Chikmagalur]

> I can see the problem.
> But what would you expect to happen if there was no attachment in the
> original directory? Should the attachment be created relative to the
> original file? To the symlink?

I don't know.  I would expect the attachment to always be created
relative to the original file, but other users might have the opposite
expectation.

Karthik

Re: [BUG] Attachments not resolved correctly from symlinked Org files

[Ihor Radchenko]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

>> I can see the problem.
>> But what would you expect to happen if there was no attachment in the
>> original directory? Should the attachment be created relative to the
>> original file? To the symlink?
>
> I don't know.  I would expect the attachment to always be created
> relative to the original file, but other users might have the opposite
> expectation.

What about the approach we already use in
`org-attach-id-to-path-function-list' - check if an attachment directory
already exists, generated using any rule, and only if not, create a new?

Similarly, in `org-attach-dir', we can first check local attachment
directory and return it if it exists. Then, we check attachment
directory for the symlink source, and return it when it exists.
If none exists, create attachment locally or relative to the symlink
source, according to some customization. The default will be creating
locally, to follow the existing behavior.

-- 
Ihor Radchenko // yantar92,
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>

Re: [BUG] Attachments not resolved correctly from symlinked Org files

[Ihor Radchenko]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

Ihor Radchenko <yantar92@posteo.net> writes:

> What about the approach we already use in
> `org-attach-id-to-path-function-list' - check if an attachment directory
> already exists, generated using any rule, and only if not, create a new?
>
> Similarly, in `org-attach-dir', we can first check local attachment
> directory and return it if it exists. Then, we check attachment
> directory for the symlink source, and return it when it exists.
> If none exists, create attachment locally or relative to the symlink
> source, according to some customization. The default will be creating
> locally, to follow the existing behavior.

See the attached tentative patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-attach-dir-from-id-Search-existing-attachments-f.patch --]
[-- Type: text/x-patch, Size: 4855 bytes --]

From add9e512fa80e53bfa396ebc4d0bdf35b3bee089 Mon Sep 17 00:00:00 2001
Message-ID: <add9e512fa80e53bfa396ebc4d0bdf35b3bee089.1717493559.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Tue, 4 Jun 2024 11:30:44 +0200
Subject: [PATCH] org-attach-dir-from-id: Search existing attachments for
 symlinks

* lisp/org-attach.el (org-attach-dir-from-id): When current buffer
displays a symlinked file, search for existing attachments in the
original file dir.
* etc/ORG-NEWS (=org-attach= now considers symlinked files when
searching pre-existing attach dirs): Announce the change.

Reported-by: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
Link: https://orgmode.org/list/87seyydnf7.fsf@localhost
---
 etc/ORG-NEWS       |  8 ++++++++
 lisp/org-attach.el | 39 +++++++++++++++++++++++++++++----------
 2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4b0b77ca8..4ac88f139 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -41,6 +41,14 @@ all the references are resolved in the generated png.
 # This also includes changes in function behavior from Elisp perspective.
 
 ** Miscellaneous
+*** =org-attach= now considers symlinked files when searching pre-existing attach dirs
+
+When Org buffer is opened from a symlink, Org mode looks into the
+original file directory when searching if an attach directory already exists.
+This way, attachments will remain accessible when opening symlinked Org file.
+
+When no attach dir exists, Org mode will still prefer creating it in
+the "default" directory - where the symlink is located.
 
 * Version 9.7
 
diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 16f6e1e29..d4bff03ad 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -433,22 +433,42 @@ (defun org-attach-dir-get-create ()
       (make-directory attach-dir t))
     attach-dir))
 
-(defun org-attach-dir-from-id (id  &optional existing)
+(defun org-attach-dir-from-id (id &optional existing)
   "Return a folder path based on `org-attach-id-dir' and ID.
 Try id-to-path functions in `org-attach-id-to-path-function-list'
 ignoring nils.  If EXISTING is non-nil, then return the first path
-found in the filesystem.  Otherwise return the first non-nil value."
+found in the filesystem.  Otherwise return the first non-nil value.
+
+The existing paths are searched in
+1. `org-attach-id-dir';
+2. in \"data/\" dir - the default value of `org-attach-id-dir';
+3. if current buffer is a symlink, (1) and (2) searches are repeated
+   in the `default-directory' of symlink target."
   (let ((fun-list org-attach-id-to-path-function-list)
         (base-dir (expand-file-name org-attach-id-dir))
-        (default-base-dir (expand-file-name "data/"))
+        (fallback-dirs (list (expand-file-name "data/")))
         preferred first)
+    (when (and (buffer-file-name)
+               (file-symlink-p (buffer-file-name)))
+      (let ((default-directory
+             (file-name-directory
+              (file-truename (buffer-file-name)))))
+        (cl-pushnew (expand-file-name org-attach-id-dir) fallback-dirs)
+        (cl-pushnew (expand-file-name "data/") fallback-dirs)))
+    (setq fallback-dirs (delete base-dir fallback-dirs))
+    (setq fallback-dirs (seq-filter #'file-directory-p fallback-dirs))
     (while (and fun-list
                 (not preferred))
       (let* ((name (funcall (car fun-list) id))
              (candidate (and name (expand-file-name name base-dir)))
-             ;; Try the default value `org-attach-id-dir' as a fallback.
-             (candidate2 (and name (not (equal base-dir default-base-dir))
-                              (expand-file-name name default-base-dir))))
+             ;; Try the default value `org-attach-id-dir', and linked
+             ;; dirs if buffer is a symlink as a fallback.
+             (fallback-candidates
+              (and name (mapcar
+                         (lambda (dir) (expand-file-name name dir))
+                         fallback-dirs)))
+             (fallback-candidates
+              (seq-filter #'file-directory-p fallback-candidates)))
         (setq fun-list (cdr fun-list))
         (when candidate
           (if (or (not existing) (file-directory-p candidate))
@@ -456,10 +476,9 @@ (defun org-attach-dir-from-id (id  &optional existing)
             (unless first
               (setq first candidate)))
           (when (and existing
-                     candidate2
-                     (not (file-directory-p candidate))
-                     (file-directory-p candidate2))
-            (setq preferred candidate2)))))
+                     fallback-candidates
+                     (not (file-directory-p candidate)))
+            (setq preferred (car fallback-candidates))))))
     (or preferred first)))
 
 (defun org-attach-check-absolute-path (dir)
-- 
2.45.1


[-- Attachment #3: Type: text/plain, Size: 225 bytes --]



-- 
Ihor Radchenko // yantar92,
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>