Desktop apps can read and write the user's filesystem, not only a sandbox

What it is

A desktop app opens any folder under Documents, saves the result to a USB stick, and watches a directory for new files. Those acts hold by default because the app can read and write the user’s filesystem, rather than living in its own container and seeing only a few allowed copies. Direct filesystem access is the capability gap between desktop and mobile sandbox: files are the user’s objects, paths are chosen by the user, the app is a visitor. That sandboxing is tightening this capability is a different entry. This one is only how “can read and write directly” shapes desktop interaction, and how it differs from “can only act inside a container.”

Why it happens

Mobile apps keep data in a private container; people have no machine-wide file map. Desktop treats the disk as space the user already owns. Open/Save dialogs, Finder/Explorer, and the shell are different doors onto the same map. Direct access makes “the document lives outside the app” the default model: people classify with folders, edit the same file with another tool, and let backup software take it by path. If an app writes documents only into its own container, desktop users think the file is lost—not lost on disk, lost off their map. The capability also couples the app to assumptions: paths change, someone else opens the file, the disk fills, permissions flip mid-session. The container model drops those assumptions and, with them, the user’s own file tools.

Studying it

Compare the same task on a product that saves to an arbitrary path and one that saves only into an app library. After save, have people find the file in Finder/Explorer, or open it with another app.

Independent variables: whether the save location is user-chosen, whether the app library is exposed as a real folder, whether “Show in folder” exists. Dependent variables: whether people can locate the file in the system file manager after save, whether another app can open it, the sense of “who owns this file now.”

A lab that only clicks Open/Save inside the app never tests whether a map formed. Force one retrieval outside the app. Developer participants often accept containers because they know the library path; target users search by folder, and failure is narrated as “I don’t know how to use this software.”

Where it stops holding

Browsers and store-distributed desktop apps already live halfway in a container; tolerance for “cannot open an arbitrary path” is rising. Professional tools (images, code, scientific data) still treat arbitrary paths as the bar. Pure cloud documents move the map onto a website; the local filesystem is no longer home, and this claim weakens. Portable apps running from a USB stick read and write that volume, not the home directory; the map follows the executable. Encrypted volumes and enterprise policy turn “direct” into “direct, but only on allowed drive letters”: the capability remains, the range is cut by policy.

Applying it

• Let people specify open and save paths by default, and treat that path as the document’s identity; do not write only into an app library and tell them it is saved.
• Offer “Show in folder / Reveal in Explorer” so the system file map and the in-app list coincide.
• Keep private caches apart from user documents; deleting the app must not take files on user-chosen paths with it.
• Verify: save a file, quit the app completely, find it only with the system file manager, and open it with another app. If it cannot be found, or is only visible inside the original app, a desktop document was made into a container object. Uninstall the app; files on user-chosen paths should still be there.

Related

• Within the group: K2.12.2 OS differences in paths and naming break cross-platform ports · K2.12.3 Apps that touch the filesystem must handle concurrent external edits · K2.12.4 Sandboxing requires apps to declare and request a file-access scope
• Adjacent: E2.15 File upload · H1.08 Autosave of drafts
• Search terms: direct filesystem access · app sandbox · document-centric