Skip to content

feat(datamap): write new uploads to ~/Documents/Autonomi/Datamaps/#98

Open
Nic-dorman wants to merge 2 commits into
mainfrom
feat/datamap-user-addressable-dir
Open

feat(datamap): write new uploads to ~/Documents/Autonomi/Datamaps/#98
Nic-dorman wants to merge 2 commits into
mainfrom
feat/datamap-user-addressable-dir

Conversation

@Nic-dorman
Copy link
Copy Markdown
Contributor

Summary

Fixes the macOS gap where NSOpenPanel hides `/Library` by default in the OS file picker, leaving users unable to navigate to their own datamaps. New uploads now land in `/Documents/Autonomi/Datamaps/` (or the platform equivalent), where every OS picker can reach them.

Zero impact on existing users

Detection is stateless on every `write_datamap_for` call:

Install state Behavior
Existing — `config_path()` already has `.datamap` files Keep writing there. No surprise, no scattered state.
Fresh — no `.datamap` files in legacy dir Write to `~/Documents/Autonomi/Datamaps/`.

The rule is stable across subsequent writes:

  • Existing installs accumulate datamaps in the legacy dir → rule continues to choose legacy. Old datamaps stay reachable via the row affordance (Copy Path / Reveal / DownloadByDatamapDialog list).
  • Fresh installs never write to the legacy dir → rule continues to choose Documents.

No migration, no config field, no `upload_history.json` rewrite. Existing entries' absolute paths still resolve.

Files changed

`src-tauri/src/config.rs` only:

  • New `datamap_dir()` — fresh-install default (`~/Documents/Autonomi/Datamaps/`)
  • New `resolve_datamap_output_dir()` — picks legacy vs new based on legacy dir contents
  • `write_datamap_for` uses `resolve_datamap_output_dir()` instead of `config_path()`

Privacy caveat (documented in commit)

`/Documents` is commonly synced by iCloud Drive / OneDrive. A datamap is the key to private data on the network — users who don't want cloud sync exposure can exclude the folder at the sync layer. Same control surface as any other file in Documents. Pre-this-PR the keys lived in non-synced `/Library` / `%APPDATA%`; this is a deliberate trade-off favoring discoverability over default-off cloud exposure.

Test plan

  • CI build clean
  • Existing-user simulation (Windows): with `.datamap` files already in `%APPDATA%\autonomi\ant-gui\, upload a new file. Confirm the new datamap lands in \%APPDATA%\autonomi\ant-gui\` (not Documents). Re-download an old entry — works.
  • Fresh-install simulation: rename `%APPDATA%\autonomi\ant-gui\ to back it up. Launch the app. Upload a file. Confirm the new datamap lands in \%USERPROFILE%\Documents\Autonomi\Datamaps\`. Open the OS picker via Download by Datamap → Browse — confirm you can navigate to and open the new datamap.
  • macOS (manual UAT on a Mac): verify the picker can navigate into `~/Documents/Autonomi/Datamaps/` (it should — that's the whole point).
  • Existing entry's Copy Path / Reveal still resolves the legacy location.

Stacks with

This PR conflicts only on `write_datamap_for` with #97 (V2-258: msgpack write). Whichever lands first, the second is a trivial rebase — both touch only that function's body.

🤖 Generated with Claude Code

Nic-dorman and others added 2 commits May 12, 2026 11:44
Fixes the macOS gap where NSOpenPanel hides ~/Library by default, leaving
users unable to navigate the OS file picker to their own datamaps. New
uploads now land in ~/Documents/Autonomi/Datamaps/ (or the platform
equivalent of Documents), where every OS picker can reach them. Also
helps users sharing datamaps across machines via iCloud Drive / OneDrive
— Documents is the natural sync target for that flow.

Detection is stateless on every write:

* If config_path() already contains any .datamap files → keep writing
  there. Existing installs are not disrupted; their old datamaps stay
  alongside any new ones, and the row affordance (Copy Path / Reveal /
  click basename in DownloadByDatamapDialog) keeps finding them by the
  absolute path stored in upload_history.json.

* Otherwise → write to the new user-addressable dir. Fresh installs get
  the picker fix immediately.

The detection is stable after each write: existing installs keep the
.datamap files in the legacy dir forever (the rule continues to find
them); fresh installs never accumulate .datamap files in the legacy dir
(the rule continues to choose the new one).

No migration, no config field, no breaking change. Existing users see
zero behavior change unless they manually delete all their old datamap
files — in which case the next write flips to the new location, which
is the right behavior at that point.

Privacy note: ~/Documents is commonly synced by iCloud Drive / OneDrive
by default. A datamap is the key to private data on the network. Users
who don't want cloud sync exposure for new datamaps can opt out at the
sync layer (exclude the folder from sync) — same control surface as any
other file in Documents.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant