Bug 424340

Summary:	PDF bookmarks not found when opening document by symbolic link
Product:	[Applications] okular	Reporter:	Grzegorz Kowzan <kan.nokt>
Component:	general	Assignee:	Okular developers <okular-devel>
Status:	RESOLVED FIXED
Severity:	minor	CC:	aacid, nate, yumpusamongus+kde
Priority:	NOR
Version First Reported In:	1.10.2
Target Milestone:	---
Platform:	unspecified
OS:	All
Latest Commit:	https://invent.kde.org/graphics/okular/commit/caa351c723c906cb2f675e298a17427928b7abd3	Version Fixed In:	1.12.0
Sentry Crash Report:

Description Grzegorz Kowzan 2020-07-17 16:18:23 UTC

SUMMARY
Bookmarks for a PDF document not found when the document is opened through a symbolic link.

STEPS TO REPRODUCE
1. Create a folder ~/dir_x and a symbolic link to it at ~/dir_y.
2. Open file ~/dir_x/file.pdf and create a bookmark.
3. Open the same file through ~/dir_y/file.pdf path, bookmark is not found.

POSSIBLE SOLUTION
Resolve absolute path when opening a file or compare absolute paths when looking for bookmarks.

Comment 1 Bug Janitor Service 2020-07-22 23:30:06 UTC

A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/224

Comment 2 Albert Astals Cid 2020-08-08 10:48:02 UTC

Git commit caa351c723c906cb2f675e298a17427928b7abd3 by Albert Astals Cid.
Committed on 07/08/2020 at 22:34.
Pushed by aacid into branch 'master'.

Bookmarks: Resolve symlinks before using an url

If a symlink points to another file, we should use that file as
canonical source for bookmarks, it doesn't make sense to have two
different sets of bookmarks for two paths that are essentially the same
file

M  +34   -14   core/bookmarkmanager.cpp
M  +14   -14   core/bookmarkmanager.h

https://invent.kde.org/graphics/okular/commit/caa351c723c906cb2f675e298a17427928b7abd3

Comment 3 Russell Haley 2024-12-09 15:27:16 UTC

The "fix" has created the opposite problem -- the bookmarks.xml file has absolute paths in it, which I discovered with a precautionary recursive grep before re-aiming a symlink to a new mount point. These would've broken had I not found them.

IMO, looking "behind" symlinks is not something applications should do except to avoid loops or protect users from themselves, such as a text editor unsaved modifications to open files.  Resolving and storing absolute paths like this seems to defeat the intent of the user/admin who created the symlink.  Do I need to start bind mounting instead?

Comment 4 Albert Astals Cid 2024-12-09 21:23:00 UTC

Do not reopen a 4 year old bug.

If you think there is a bug now, please file a bug.