Windows DX: add portable Dev Drive setup alongside the installer

[JanJakes]

Context

PR #36 adds the right Windows-native storage direction: ReFS block cloning on a Dev Drive, plus ForkPressSetup.exe for the fresh-laptop click-through flow.

This issue tracks the next Windows DX question: keep the installer, but also consider exposing the same setup flow from the standalone forkpress.exe binary.

Refs #6 and #36.

Current assessment

ReFS Dev Drive still looks like the best Windows-native COW path for ForkPress.

• NTFS does not provide the ordinary-file COW primitive ForkPress needs.
• NTFS hardlinks are not enough because writes affect the same file identity.
• NTFS junctions/symlinks/reparse points redirect paths but do not provide block-level copy-on-write isolation.
• VSS snapshots are volume-level snapshots, not normal writable branch directories.
• Full copy on NTFS is correct but defeats the cheap-branch goal.
• WinFsp/Dokany/FUSE-style options require a driver/runtime install, extra security surface, and a mounted provider process.
• ProjFS may be worth revisiting for lazy branch namespaces, but it is a different architecture and requires an optional Windows component plus a provider process.
• Cloud Files API is more sync/hydration-shaped than general writable COW branch storage.
• WSL/Docker violate the intended native, ordinary Windows path UX.

The main advantage of ReFS Dev Drive is that ForkPress gets normal Windows paths while the filesystem provides block clone isolation. PHP, Git, editors, Explorer, backup tools, and antivirus all see ordinary files.

Installer vs portable setup

The installer is not strictly required by the storage technology. A portable standalone forkpress.exe could, in theory, perform the same setup.

However, a fresh Windows setup still needs an elevated setup flow because it may need to:

• request UAC/admin rights;
• create a VHDX under protected storage;
• format it as ReFS/Dev Drive;
• mount it at a stable user path such as %USERPROFILE%\ForkPressDevDrive;
• trust the Dev Drive;
• register auto-mount after login;
• install or verify the VC++ runtime needed by bundled PHP;
• add forkpress.exe to PATH;
• create the first site and shortcuts.

ForkPressSetup.exe remains the best non-technical user flow: download, double-click, accept UAC, open Start ForkPress Site.

A CLI setup command would improve the developer/portable story without replacing the installer.

Proposal

Keep ForkPressSetup.exe, but add a first-class command such as:

forkpress setup windows-dev-drive

Possible responsibilities:

• detect whether the current machine supports Dev Drive/ReFS block cloning;
• explain why NTFS is not sufficient for cheap COW branches;
• self-elevate or print a precise elevated rerun command;
• create/attach the ForkPress Dev Drive VHDX;
• format/trust/mount the Dev Drive;
• register auto-mount;
• optionally initialize the first site;
• optionally create shortcuts;
• make forkpress init on NTFS fail closed with a clear pointer to this command or the installer.

Product direction

Recommended Windows DX shape:

• Keep the installer for fresh laptops and non-technical users.
• Add forkpress setup windows-dev-drive for portable/developer workflows.
• Keep ReFS Dev Drive as the primary Windows COW solution.
• Treat NTFS full-copy as an explicit degraded fallback only if we decide that tradeoff is acceptable.
• Avoid FUSE/WinFsp/Dokany unless ForkPress intentionally changes product shape to include a filesystem provider/driver dependency.

References

• Microsoft ReFS block cloning: https://learn.microsoft.com/en-us/windows-server/storage/refs/block-cloning
• Microsoft Dev Drive docs: https://learn.microsoft.com/en-us/windows/dev-drive/
• Microsoft ProjFS docs: https://learn.microsoft.com/en-us/windows/win32/projfs/projfs-programming-guide