Relative Paths in file links don't work (incorrect handling of double-dot ..)

Relative paths in file:// links do not work correctly.

Double-dots, such as in file://../zotero/storage, are ignored, causing Logseq to wrongly resolve this path to logseq/assets/zotero/storage.

This issue breaks @Aryan’s new Zotero plugin.

as it interprets relative paths as paths inside of assets.

Here is a concrete example of a relative path pointing outside of the Logseq folder being interpreted incorrectly:

This might be the same issue: Citations of annotations on PDF file opened via zotero link do not work on another computer

A similar issue has been fixed for audio files. Support relative path in audio component

A related feature request: Relative path for Zotero data directory

This would be extremely convenient, if not essential, for cross-platform usage (via third-party syncing).

It’s currently the only thing that makes it impossible for me to use logseq in my daily workflow.

Edit: a temporary workaround is to use the fact that “.” folder is consistently a relative file path and systematically resolves to “assets/path”. For Paperpile users for example, a tweak is to move your “Paperpile” Google Drive folder into logseq’s “assets” (given that you store your logseq in the same Google Drive). Paperpile won’t break (even if you rename this folder) then you will be able to retrieve pdfs from “.” relative paths cross-platform (even highlights in hls_ pages will keep “.” relative paths). I believe a same idea can be applied with Zotero. Note that for best behavior, “.” should be omitted: paths should resemble “assets/path” and not “./assets/path”.

1 Like