Skip to content

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

Merged
Nic-dorman merged 1 commit into
mainfrom
feat/datamap-user-addressable-dir
May 14, 2026
Merged

feat(datamap): write new uploads to ~/Documents/Autonomi/Datamaps/#98
Nic-dorman merged 1 commit 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

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>
@Nic-dorman Nic-dorman force-pushed the feat/datamap-user-addressable-dir branch from 0992882 to 72b46f9 Compare May 14, 2026 16:34
@Nic-dorman Nic-dorman merged commit fb1db33 into main May 14, 2026
4 checks passed
@Nic-dorman Nic-dorman deleted the feat/datamap-user-addressable-dir branch May 14, 2026 16:35
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