FIELD NOTES / BUILDING IN THE OPEN ABOUT THE LIMITS
Show the work.
Keep the receipts.
MountMe is a working Windows prototype. These notes distinguish tested behavior from ambitions. The source repository is currently private; public downloads aren't available yet.
Visible progress. Real controls.
The current development build includes S3/MEGA S4 and Azure Blob browsing, read-only Windows mounts, direct uploads, a disk-backed folder/drive queue, cancellation, and restart recovery. Average speed and active elapsed time explain effective progress; skipped objects and paused time are excluded.
Conflict choices let you skip existing bucket/key pairs, choose conditional replacement, or ask per object with apply-to-all decisions. This isn't content-based deduplication. Conditional writes protect against replacing an object that changed after inspection.
What has actually been checked?
- Local S3 and Azure fixtures exercise byte-range reads, source changes, destination races, dropped replies, cancelled requests, multipart recovery, and real Windows read-only filesystem behavior.
- Three original files were uploaded to a live MEGA S4 account, including small and multipart objects. Independent full-file downloads matched their source SHA-256 hashes.
- A live cancellation test stopped an active multipart upload. MEGA later reported that the upload ID no longer existed. Recovery restarted that file under a fresh ID; its completed object passed independent full-file hash comparison.
- A larger volume test was stopped on request. Its inventory was not completed; sources and recovery state were retained.
Azure Blob joins the preview.
The new Azure provider browses private containers, mounts a read-only Windows drive, and uses the same visible transfer controls. Account-key and SAS sessions are supported. A small live Azure proof cancelled after an accepted block, resumed from its saved checkpoint, and independently verified all three synthetic files with complete SHA-256 readbacks. The large file also matched through a real mounted drive. This is a small proof, not a sustained volume result.
A little more hands-on.
The new opt-in write preview supports copying files and folders into one bucket/container and editing existing files in place. It requires an explicitly chosen local staging folder and hard capacity limit. The Writeback Desk separates local saves from later cloud confirmation. Staged copies are retained, even after upload, and still count against the limit.
Local S3 and Azure tests exercised actual Windows copy, hydration, seek/edit/truncate, folders, destination conflicts, and cancellation with fresh-workspace recovery. This is fixture proof, not live MEGA/Azure writable-mount or sustained-volume proof. Rename/delete, temporary-file replacement saves, automatic staging eviction, and general editor compatibility remain outside this slice. Read-only mounting stays the default.
The next stretch
More provider coverage, sustained volume results, clearer diagnostics, worker isolation, better throughput controls, and signed distribution. Broader writable compatibility still needs rename/delete, conflict-resolution, eviction, crash, and live-provider work.
Portable doesn't mean driver-free
The app is distributed as an extracted folder with its runtime. Read-only drive mounting requires a separately installed Dokan runtime. Browsing and direct uploads are separate from that driver prerequisite.