Internal link (#loc:…) never resolves — owner and recipient both land on their own Personal root #677

New issue

Closed

opened 2026-09-23 03:16:28 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-23 03:16:28 +00:00

Owner

Found by the #656 QA pass (v0.6.247, both dogfoods).

Matrix row: §4 Sharing — "Internal link | Copy internal link, open as recipient with access | Resolves to the file; grants nothing on its own".

Steps

files-bao as nikola-test: _qa/qa-drop.txt → pane → Shares. The internal link field shows https://files-bao.c0rdyceps.ch/#loc:%2Fhome%2F_qa%2Fqa-drop.txt, and sharer1 holds a grant on the file.
Owner: open that exact URL fresh in a new navigation. The app rewrites the hash to #/home and shows the Personal root, with no pane and no highlight. Reproduced twice.
Recipient (sharer1, has access): load the same URL. It also lands on sharer1's own Personal root (#/home), silently.
files, as nikola-test: #loc:%2Fhome%2F_qa%2Fqa-note.md on a fresh load → #/home root. A hash-only change to a #loc: link while the app is loaded does nothing at all.

Expected: the link opens the file (its folder with the pane on it) for anyone who already has access. For the recipient, that means the /shared/nikola-test/… view.
Seen: the link resolves for nobody, on either host. The link also encodes the owner-relative virtual path /home/_qa/…, which even if resolved would point into the recipient's own home. The link needs an owner-independent identifier (owner + path, or a file id) to meet the "resolves for recipient" half of the row.

Side note: one fresh load of a #loc: link on files (for qa-doc.pdf) hung the tab's renderer (CDP timeouts for more than 60s; the tab had to be closed). It did not reproduce with qa-note.md, so it is not filed. Mentioned in case a PDF-specific path loops.

Screenshot: none saved. The only visible state is the Personal root with real (non-_qa) dogfood content, which I did not capture. The hash rewrite quoted above is the evidence.

Found by the #656 QA pass (v0.6.247, both dogfoods). **Matrix row:** §4 Sharing — "Internal link | Copy internal link, open as recipient with access | Resolves to the file; grants nothing on its own". **Steps** 1. files-bao as nikola-test: `_qa/qa-drop.txt` → pane → Shares. The internal link field shows `https://files-bao.c0rdyceps.ch/#loc:%2Fhome%2F_qa%2Fqa-drop.txt`, and sharer1 holds a grant on the file. 2. **Owner:** open that exact URL fresh in a new navigation. The app rewrites the hash to `#/home` and shows the Personal root, with no pane and no highlight. Reproduced twice. 3. **Recipient (sharer1, has access):** load the same URL. It also lands on sharer1's **own** Personal root (`#/home`), silently. 4. files, as nikola-test: `#loc:%2Fhome%2F_qa%2Fqa-note.md` on a fresh load → `#/home` root. A hash-only change to a `#loc:` link while the app is loaded does nothing at all. **Expected:** the link opens the file (its folder with the pane on it) for anyone who already has access. For the recipient, that means the `/shared/nikola-test/…` view. **Seen:** the link resolves for nobody, on either host. The link also encodes the owner-relative virtual path `/home/_qa/…`, which even if resolved would point into the *recipient's* own home. The link needs an owner-independent identifier (owner + path, or a file id) to meet the "resolves for recipient" half of the row. Side note: one fresh load of a `#loc:` link on files (for `qa-doc.pdf`) hung the tab's renderer (CDP timeouts for more than 60s; the tab had to be closed). It did not reproduce with `qa-note.md`, so it is not filed. Mentioned in case a PDF-specific path loops. **Screenshot:** none saved. The only visible state is the Personal root with real (non-`_qa`) dogfood content, which I did not capture. The hash rewrite quoted above is the evidence.