Three things from testing.
── The download zip carried the path to itself ──
Selecting files in ~/Tests/test_folder and downloading produced an archive whose
contents were `Tests/test_folder/…`. `POST /download` spawned zip with
`cwd: rootDir` and root-relative paths, so the whole chain from home went in.
Nobody selecting three files is asking for the route to that folder to be part of
what they downloaded.
Now it zips from the items' own folder using bare names. A MIXED selection keeps
the old form, because two `notes.txt` from different folders would collide
without the paths keeping them apart — the UI only selects within one folder, so
that branch is a safety net rather than the case. `/compress` already did it this
way; this is the same fix on the endpoint that predates it.
Verified against real zip: `Tests/a.txt` → `a.txt`, `Tests/test_folder/b.txt` →
`test_folder/b.txt`.
── Double-clicking an archive extracts it ──
It opened a pane that rendered "Archive file" and the name you could already see
in the listing. That is a step on the way to the only thing anyone opens a zip
for. Extract resolves collisions, so a second double-click makes a sibling rather
than overwriting. The menu's Extract stays — a double-click is not a discoverable
way to learn what will happen.
── Show location ──
A search result answers "here is the file"; its path underneath raises "where does
this live", and clicking only ever answered the first. This goes to the containing
folder, clears the search and SELECTS the row, so a folder of forty files does not
leave you hunting. A directory hit reveals its parent — where is this means the
folder it sits in, not the folder it is.
tsgo clean, frontend builds, 817 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5
a84eedd126