Bug 478056 - Linked Documents are opened via resolved path, not given path
Summary: Linked Documents are opened via resolved path, not given path
Status: RESOLVED FIXED
Alias: None
Product: KBibTeX
Classification: Applications
Component: User interface (show other bugs)
Version: git (master)
Platform: NixOS Linux
: NOR normal
Target Milestone: ---
Assignee: Thomas Fischer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-04 16:06 UTC by nobodyinperson
Modified: 2023-12-15 23:39 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.10.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nobodyinperson 2023-12-04 16:06:28 UTC
SUMMARY

The linked documents (`localfile=...`, available in the context-menu or via CTRL+D) are opened by fully resolving their path, getting rid of all symlinking along the way. Instead, the user-specified path should be used. This is necessary when the linked PDFs are stored behind symlinks, as is the case with e.g. git-annex, where the target PDF has a cryptic name, which then shows up as PDF title in PDF viewers when opened from KBibTeX.


STEPS TO REPRODUCE
1. Make a `.bib` file with content:

```
@article{empty,
        localfile = {linked.pdf},
        title = {{empty}}
}
```

2. Put a PDF next to it, called `original.pdf`
3. Create a link to the PDF: `ln -rsf original.pdf linked.pdf`
4. Open the `.bib`-file with KBibTeX
5. Click on the only entry called `empty`
6. Hit CTRL+D or right-click -> View Document

OBSERVED RESULT

PDF viewer is opened with file `original.pdf`

EXPECTED RESULT

PDF viewer is opened with file `linked.pdf`

SOFTWARE/OS VERSIONS

NixOS or Manjaro with XFCE.

ADDITIONAL INFORMATION

I browsed and debugged the code (seems like it happens in `src/parts/part.cpp`), but was unable to find where exactly the path resolution happens.
Comment 1 Thomas Fischer 2023-12-15 21:57:08 UTC
If I understood the problem correctly, it was sufficient to replace QFileInfo::canonicalFilePath() with QFileInfo::absoluteFilePath() at a few locations. Please test and confirm.

https://invent.kde.org/thomasfischer/kbibtex/-/commit/4ff1ad50249d58b1315f296d5866d420c8050856
Comment 2 nobodyinperson 2023-12-15 22:39:28 UTC
Thank you very much Thomas, this is it! The linked documents are now opened as the unresolved symlink, which improves usability big time for me. Amazing! 🥳
Comment 3 Thomas Fischer 2023-12-15 23:09:16 UTC
Git commit 46fcd010575a577bca750afd7155b304ef6e5e39 by Thomas Fischer.
Committed on 16/12/2023 at 00:08.
Pushed by thomasfischer into branch 'kbibtex/0.10'.

Using absolute paths, not canonical paths

In the previous behaviour, absolute paths where used when showing file paths
to the user. In absolute paths, symbolic links are resolved to the actual
file and path names. However, it may be in the user's interest to use
human-readable symbolic links that point to 'cryptic' actual filenames. Thus,
it is better to keep the symbolic links.
FIXED-IN: 0.10.1

M  +1    -0    ChangeLog
M  +6    -6    src/io/fileinfo.cpp

https://invent.kde.org/office/kbibtex/-/commit/46fcd010575a577bca750afd7155b304ef6e5e39
Comment 4 Thomas Fischer 2023-12-15 23:39:56 UTC
Git commit 754c8b688d06d9e1216b93aa92251e7fa81538b0 by Thomas Fischer.
Committed on 16/12/2023 at 00:34.
Pushed by thomasfischer into branch 'master'.

Using absolute paths, not canonical paths

In the previous behaviour, absolute paths where used when showing file paths
to the user. In absolute paths, symbolic links are resolved to the actual
file and path names. However, it may be in the user's interest to use
human-readable symbolic links that point to 'cryptic' actual filenames. Thus,
it is better to keep the symbolic links.

Cherry-pick of commit 46fcd010575a577bc from branch 'kbibtex/0.10'.

M  +1    -0    ChangeLog
M  +5    -5    src/io/fileinfo.cpp

https://invent.kde.org/office/kbibtex/-/commit/754c8b688d06d9e1216b93aa92251e7fa81538b0