Drive feature unstable with uploads and downloads on Debian

[joshsol1]

Rustguac server is Debian 13.
Debian 12 Jumpbox.

Drive feature is enabled, not using luks currently with the following settings.

[drive]
enabled = true
drive_path = "/home/rustguac"
drive_name = "Shared Drive"
allow_download = true
allow_upload = true
cleanup_on_close = false

Issues:

• When uploading using the side panel the session immediately disconnects and requires reconnection.
• With cleanup_on_close = false set, all files still disappear during disconnect and reconnect or relaunching a connection.
• With cleanup_on_close = false set and retention_secs = 0 set, retention_secs wins and cleanup_on_close is ignored. (Not a bug but should be in documentation.)
• When dropping something in the download folder you then need to open the side Files tab, refresh the panel and then click download on the file/folder. Dropping something in the download folder should cause the browser to automatically download the file/s.

[davekempe]

Hi Josh - thanks for the detailed report. Splitting the four items by status:

Fixed locally on main (will ship in v1.6.8):

• Item 2 (cleanup_on_close = false ignored) and item 3 (retention_secs = 0 overriding cleanup_on_close) had the same root cause: cleanup_browser in src/session.rs hardcoded retention_secs = 0 and never read the flag at all, so both settings were dead code at end-of-session teardown. The fix routes both values from the resolved [drive] config through to the cleanup call. Three unit tests covering the resolution.
• The docs gain a "Cleanup behaviour" subsection making the precedence explicit (your item 3 doc request): retention_secs only takes effect when cleanup_on_close = true. Also documents the per-session UUID subdirectory model — even with cleanup_on_close = false, files do not persist across reconnects because each new session gets its own subdir under drive_path. Cross-session persistence (a "personal drive" model) would be a separate feature.

Postponed to a later round:

• Item 1 (side-panel upload disconnects the session immediately) - this needs a real reproducer with logs to investigate. The upload path goes browser → WebSocket → guacd as file/body/end instruction streams; with the boundary-alignment changes we made for deps: bump russh from 0.60.1 to 0.60.2 #119/deps: bump rustls from 0.23.39 to 0.23.40 #120 stability there's a non-zero chance of a regression here, but I can't tell without seeing it land. Could you confirm what version of rustguac you were testing against? (dpkg -l rustguac or check the /health endpoint output.) When you next reproduce, journalctl -u rustguac -n 200 --since "5 min ago" around the disconnect would help.
• Item 4 (dropping into the download folder should auto-download) - this is a UX change in static/client.html's file panel handlers, not a one-liner; it'll get its own ticket once we've cleared item 1.

I'll update here when v1.6.8 is cut. Thanks again for the careful repro steps - the cleanup precedence one in particular was a confused read of the code, very useful to have it spelled out.

[davekempe]

Reopening — only items 2 and 3 (cleanup_on_close / retention_secs) shipped in v1.6.8. Items 1 (upload disconnects session) and 4 (drag-drop auto-download) are still pending, see my earlier comment for the split. We'll track those here.