The "my app needs a real file path" problem

SOLUTIONS · DESKTOP APP COMPATIBILITY

IT teams move to cloud storage, some applications break, and the blame goes around: was it a bad migration, a bad configuration, or an application vendor who hasn't kept up? Often it is none of those. It is a real architectural mismatch between what many Windows desktop applications expect from their storage and what cloud storage products natively provide. This piece explains why the mismatch exists, which applications it affects, why the obvious workarounds fall short, and the category of tool that resolves it without asking anyone to rewrite anything.

Written for the IT admin who has just heard "we tried moving the shared drive to OneDrive and AutoCAD stopped saving properly" for the third time this quarter, and who wants to understand whether that's fixable in principle or a permanent constraint on the migration.

What "real file path" actually means

A real file path is one where a Windows application can perform standard Win32 filesystem operations (open, read, write, seek, lock, memory-map, delete) against a local file path (C:\path\to\file.xyz) or a mapped network path (Z:\path\to\file.xyz) and expect the operating system to handle it as it always has.

The Win32 file API has been architecturally stable since Windows NT. Every desktop application written for Windows in the last 30 years used it. The behaviour is well understood: files are byte-addressable, seekable, lockable, atomically renameable, and have an associated set of metadata (size, timestamps, attributes) that the OS keeps consistent. Applications built on top of these guarantees do not just assume them; they depend on them for correctness. Multi-user document management wouldn't work without file locking. Autosave wouldn't work without atomic rename. Large CAD drawings wouldn't open at reasonable speed without memory-mapping.

Cloud storage products do not provide those guarantees natively. OneDrive is a sync client that maintains a local mirror or stub files. SharePoint Online is a browser-first web application with an HTTP API underneath. Neither is a filesystem in the Win32 sense. Applications that depend on Win32 filesystem semantics encounter these products as something foreign, and behave accordingly.

Why applications have this expectation

Most Windows desktop applications were written before cloud storage existed as a category. The vendor built the application to work against the filesystem interface that the operating system provided. That interface was stable. The application shipped, was refined, and accreted a base of customer installations. Rewriting the file I/O layer to speak a different protocol (SharePoint REST, Microsoft Graph, WebDAV) is substantial engineering work; the customer pain hasn't accumulated to the point where it's commercially urgent for most vendors, so it hasn't happened.

Beyond the historical accident, some application patterns structurally need real filesystem semantics:

Memory-mapping: CAD, GIS, some databases open very large files by mapping their contents into virtual memory and letting the OS page in only the parts being read. HTTP-based storage cannot support this.
File locking: document management systems, accounting, statutory reporting tools lock files exclusively during edit to prevent concurrent-modification corruption. The lock has to be honoured by every process that might touch the file; a lock that only exists in the local sync client's view of the world doesn't protect against another user editing the same file from another endpoint.
Byte-range reads and writes: media production tools, some engineering software, some database engines read or write specific parts of large files rather than reading whole files sequentially. Stub-file behaviour breaks this.
Cross-file references: Excel workbooks with links to sibling files, AutoCAD drawings with xref files, GIS shapefiles which are physically 4 to 8 files that must live together and be accessible as a set, database applications with associated index files. Any storage layer that changes when or where those referenced files exist breaks the references.
Plugin ecosystems: Adobe products, AutoCAD, and many DMS tools have third-party plugins that expect standard filesystem paths and standard Win32 file APIs. Even if the host application were to be updated for cloud storage, the plugins around it wouldn't be.

What cloud storage looks like from an application's perspective

To understand why applications behave differently with different cloud-storage approaches, it helps to see what each of them actually presents to a Windows application:

OneDrive Sync (traditional mode): creates a local mirror of the user's OneDrive content in a folder on the C: drive. To the application, files in the sync folder look exactly like local files, because they are. Works for most applications, until the sync scale limits bite (300,000 items), or until the local disk fills up, or until multiple users need to collaborate on the same content and the sync client's eventual-consistency model produces version conflicts.

OneDrive Files On-Demand: a variant that keeps stub files (small placeholders) locally, downloading full content on first access. The application sees the stub in File Explorer, but the stub file is not a real file: its size is not the real size, it is not directly readable, and it cannot be memory-mapped or byte-range accessed. Some applications hydrate the stub transparently on open; others fail because they read metadata before content, and get metadata that doesn't match reality.

SharePoint Online through the browser: not a filesystem at all. An application cannot open a file that lives only in SharePoint's web interface; there is no Windows file path to open. Users can download and re-upload, but this breaks collaboration and doesn't fit any real-world workflow beyond casual document viewing.

SharePoint through WebDAV (the old "Open with Explorer" pattern): presents SharePoint content as something like a filesystem in File Explorer. Microsoft has deprecated this approach; it was always unreliable, particularly for anything other than casual file browsing. Applications that lock files, memory-map, or write incrementally tend to fail in confusing ways against WebDAV.

Drive-mapping middleware: a category of tool that presents cloud storage back to Windows as a real mapped network drive with real file paths, real filesystem semantics, real locking, and no stub-file behaviour. To a Windows application, a drive-mapping middleware layer looks like a network file server. Applications work as they always did.

The specific failure modes when apps meet cloud storage

The failures that surface when a legacy application encounters cloud storage tend to follow a small number of patterns. Naming them here lets you recognise them in the wild.

File locking not respected. The application opens a file, marks it locked, and expects other users' attempts to open it to see the lock. Sync-based storage cannot enforce this: user A's sync client knows about the lock, user B's sync client does not. Two users edit; last save wins; work is lost. This is the failure mode DMS vendors care about most.

Save errors on autosave. The application writes small increments during editing (every N seconds), each of which triggers a cloud upload. The sync client queues, throttles, or times out, and the application sees a save failure. In some applications this surfaces as a red banner; in others, silently as a lost edit.

Path length breaches. Windows has a 260-character default filename limit; SharePoint has its own 400-character URL limit; various sync clients have limits below both of those. Deep folder hierarchies migrated from a legacy file server often exceed one or more of these; files at the leaf level become inaccessible with no obvious error.

Hidden file and metadata handling. Applications write auxiliary files: .tmp, .lock, ~$file.docx (Office's own lock files), Thumbs.db, .lnk shortcuts. Sync clients variously skip, corrupt, or upload-then-delete these auxiliary files. Applications that rely on them for correct operation misbehave in ways that look like the main file is broken but are actually about the auxiliary.

Byte-range operations failing. A media application opens a 12 GB video file and reads a specific 30 seconds' worth of frames from the middle. Sync-based storage requires downloading the whole file first, which the application wasn't expecting. Files On-Demand's stub cannot support byte-range access at all.

Cross-file references breaking. An Excel workbook links to a sibling workbook in the same folder; a CAD drawing xrefs a shared block library; a GIS shapefile is actually 4 to 8 files that must all be present. When the storage layer changes when or how files are available (stubs, delayed hydration, partial sync), reference resolution breaks silently.

Categories of applications where this matters most

The applications that most reliably encounter this problem cluster into a small number of categories:

CAD and BIM: AutoCAD, Bentley MicroStation, Vectorworks. Large files, cross-references, plugins.
Document management systems: iManage, NetDocuments, WorkSite, Worldox. File locking, versioning, matter-centric folder structures.
Accounting and financial software: Sage, QuickBooks Desktop, IRIS Elements, CCH, Thomson Reuters, tax software of every flavour. Exclusive file access during batch operations; strict integrity requirements.
Healthcare EHR and EMR: EPIC, Meditech, Cerner, Allscripts, and various DICOM viewers. File-based imaging, patient record attachments, workstation-shared workflows.
Media production: Adobe Premiere, DaVinci Resolve, Pro Tools, Avid Media Composer. Huge files, byte-range access, project files referencing dozens of media assets by path.
GIS: ArcGIS, QGIS. Multi-file datasets that behave as a single logical file.
Legacy line-of-business software: the internally-developed or vertically-specific applications your organisation has been running for years. Every organisation has some.

If your migration includes any of these, you will hit the real file path problem. Planning for it up front is much cheaper than discovering it in the middle of a phased rollout.

Solution categories, with honest trade-offs

Four broad approaches exist. Only one of them is a general answer; the others work in narrow slices.

1. Wait for the application vendor to add native cloud support. Some vendors have (Autodesk's cloud offerings, Bluebeam Studio, Microsoft Office's own cloud integration). Most haven't, and even those that have often keep the traditional desktop application in parallel because customers are on it. This isn't a plan; it's a wish.

2. Run the application inside Citrix or Azure Virtual Desktop with a local file server behind it. Works: the application runs in a virtual desktop, the file server is collocated with the virtual desktop hosts, everything is fast and compatible. But you've now moved the problem: you're paying for the virtual desktop, still paying for the file server, and only questionably reducing infrastructure. Cost typically goes up, not down, unless VDI was already the direction of travel.

3. Use OneDrive Files On-Demand and hope. Works for many simpler applications that read whole files sequentially and don't check metadata before opening. Breaks for the categories in the previous section. Not a general answer.

4. Use drive-mapping middleware. Presents cloud storage as a real Windows drive letter with real file paths. Applications see a real filesystem and behave correctly. File locking works, byte-range access works, cross-file references work, no stub files. Works with essentially any Windows desktop application without vendor engagement. The category answer for organisations that need to move to cloud storage without breaking their existing application estate.

Honestly, option 4 is the only general-purpose answer. If you have applications in the affected categories, you need middleware; the other approaches only work in specific circumstances.

How drive-mapping middleware fits into the answer

Drive-mapping middleware sits between Windows and cloud storage. To Windows and to every application running on it, the middleware exposes a mapped drive letter (Z:, M:, S:, whichever you configure) with real file paths, real filesystem semantics, and real file operations. Behind the drive letter, the middleware speaks Microsoft Graph or SharePoint's APIs directly, streaming file content on demand and translating filesystem operations (open/read/write/lock/close) into their cloud-storage equivalents.

From the perspective of an application, nothing has changed. AutoCAD opens a drawing from Z:\Projects\Site 42\plan.dwg the same way it would have opened it from a Windows file server. iManage locks a matter file exclusively; other users' iManage sessions see the lock. Adobe Premiere reads a specific range of a video file; the middleware streams the requested range without hydrating the whole file. Sage takes exclusive control of an accounting file during a batch run; the lock is honoured across every endpoint. The application does not know it's running against cloud storage.

Cloud Drive Mapper is our implementation of this pattern. It's built specifically around Microsoft 365 storage (OneDrive, SharePoint Online, Teams file libraries), deploys through Intune or Group Policy to Windows endpoints and virtual desktops, and requires no server-side infrastructure of its own. Other approaches exist in the wider ecosystem; the category matters more than the specific tool. What matters is that a drive-mapping layer is in place before migration, so applications never see the cloud storage in its native form.

Real examples

To make this concrete, here are five specific application behaviours that break against sync-based cloud storage and work against drive-mapping middleware:

AutoCAD with xref files. An engineer opens a master drawing that references a shared block library and a site-plan file. All three must be present at real paths. Against OneDrive Sync in Files On-Demand mode, the master opens (it's already local); the xrefs fail because the stubs haven't been hydrated. Against drive-mapping middleware, all three files resolve to real paths and open normally.

iManage matter locking. A fee-earner opens a matter document and iManage marks it exclusively locked. Against sync-based storage, another user on another endpoint opens the same file (their sync client didn't know about the lock). Against a drive-mapping middleware layer that honours SharePoint check-out, the second user sees the file as locked and cannot accidentally overwrite the first user's edits.

Sage batch runs. The accounting team runs the end-of-month batch; Sage takes exclusive access on the company data file for the duration. Against sync storage, another user touches the file (opens it, or the sync client updates metadata); the batch fails with an integrity error. Against middleware, the exclusive lock is respected at the storage layer.

Adobe Premiere project files. A video editor opens a Premiere project referencing 40 media files scattered across sibling folders. Against Files On-Demand, some clips resolve (they've been opened recently), others show as offline media (their stubs haven't been hydrated). Against middleware, all 40 resolve to real paths and stream on demand as the editor scrubs through the timeline.

Custom Excel workflows. A finance team's model workbook links to seven other workbooks in the same folder, following a pattern the finance team has evolved over five years. Against Files On-Demand, refreshing external links pauses indefinitely waiting for stubs to hydrate. Against middleware, the linked files open through their real paths and refresh completes.

Frequently asked questions

Which applications break when their files move to OneDrive?

The affected categories are CAD and BIM (AutoCAD, Bentley MicroStation, Vectorworks), document management systems (iManage, NetDocuments, WorkSite), accounting packages (Sage, QuickBooks Desktop, tax software), healthcare EHR/EMR (EPIC, Meditech), media production tools (Adobe Premiere, DaVinci Resolve, ProTools), GIS (ArcGIS, QGIS), and legacy line-of-business applications. The common thread is that these applications perform filesystem operations (locking, byte-range reads, memory-mapping, cross-file references) that HTTP-based cloud storage APIs and sync clients do not fulfil natively.

Does OneDrive Files On-Demand solve this problem?

No, only partially. Files On-Demand uses stub files: small placeholders that trigger a download when opened. Applications that check file size before opening see the stub size, not the real size; applications that memory-map or perform byte-range operations fail because the stub is not a real file; and applications with cross-file references break when only some of the referenced files are hydrated locally. Files On-Demand is fine for casual browsing and for applications that read entire files sequentially, and inadequate for the application categories above.

Is there a way to make my legacy application work with SharePoint natively?

Not without either a rewrite of the application (which the vendor has to do; you cannot), or a translation layer that presents SharePoint content back to the application as if it were a real filesystem. The rewrite path is slow to non-existent for most legacy applications because the customer pain hasn't accumulated to the point where the vendor considers it commercially urgent. The translation-layer path (drive-mapping middleware) works today, doesn't require the application to change, and works with essentially any Windows desktop application.

How does drive-mapping middleware differ from OneDrive Sync?

OneDrive Sync creates a local mirror: files exist as full copies on the endpoint. Drive-mapping middleware presents cloud storage as a virtual network drive with real file paths, streaming content on demand rather than mirroring. To a Windows application, both look like a real filesystem, but the middleware handles file locking, path length, application compatibility and large libraries in ways the sync client does not. The trade-offs: sync gives offline access to synced files at the cost of local disk usage and scale limits; middleware gives real-time access at unlimited scale at the cost of requiring a network connection to open a file.

Do I have to keep a file server around for my legacy apps?

No. The whole reason drive-mapping middleware exists as a category is to let organisations retire on-premises file servers without breaking the applications that depended on filesystem paths. The applications see a mapped drive letter that behaves like a local filesystem; behind the drive letter is SharePoint Online. See our project plan for replacing a file server with SharePoint for the full migration sequence.

Does the application vendor need to certify their app for cloud storage?

No, not when a drive-mapping middleware layer is in place. The application sees a Windows drive letter with real file paths; from its perspective, the storage is a local or network filesystem, and it operates against it using the standard Win32 file API. No certification, testing, or vendor engagement is required. This is a specific advantage of the drive-mapping approach over cloud-native SDK integration, which does require per-app work.

Try Cloud Drive Mapper against your legacy applications

The best way to see whether Cloud Drive Mapper resolves your specific application-compatibility issues is to try it. Free for 30 days; deploy to a small pilot group and point the applications at the CDM drive rather than the file server.

Start a free trial Request a demo