OneDrive's Phantom Files Were Silently Breaking My Git Repos

I keep most of my projects inside OneDrive-synced folders on my Mac. It's convenient: everything backs up automatically, I can access files from anywhere, and Finder shows the full directory tree like it's all local.

Except it's not all local. And that's the problem.

---

What "Dataless" Means

OneDrive has a feature called "Files On-Demand" (on by default). It shows files in Finder and in ls output as if they exist on disk, but some of them are just placeholders. The actual file content lives in the cloud. macOS marks these with a dataless flag that you can see with ls -laeO:

ls -laeO somefile.swift
-rw-r--r--  1 michael  staff  dataless 2048 Mar 23 10:00 somefile.swift

That file has a name, permissions, a size, and a timestamp. But its content is not on your disk. It's a phantom. Open it in Finder and macOS will quietly download it on the fly. But developer tools don't always trigger that download gracefully.

---

How This Breaks Everything

I was trying to get a Swift project running locally. The directory looked fine. ls showed every file in place. But when I started actually working, things fell apart.

Compilers expect to open a source file and read it immediately. Git expects its .git/objects/ pack files to be on disk so it can mmap them. When those files are dataless phantoms, you get:

• fatal: mmap failed: Operation timed out on git commands
• Git operations hanging indefinitely while OneDrive slowly fetches objects one by one
• Xcode builds failing with cryptic errors because source files aren't actually present
• git status working fine one moment, git log hanging the next

The worst part: git status might work perfectly because it only needs the index file and the working tree. But git log, git diff, or git checkout need to read pack files from .git/objects/, and if those are phantoms, the command either hangs waiting for OneDrive to fetch them or fails with an mmap error.

---

Finding the Phantoms

To see how many dataless files are lurking in your project:

ls -laeOR /path/to/project | rg "dataless" | wc -l

When I ran this on my project, there were over 200 dataless files. After I forced the source code to download, I checked .git/ specifically and found another 170+ phantom objects hiding in there. The source code was local, but the Git history was a minefield.

---

Force-Downloading Everything

The brute-force fix: read every file to trigger OneDrive's download. You'd think a single find . -type f -exec cat {} \; would handle it. It doesn't. OneDrive's sync client can't keep up with hundreds of simultaneous download requests. It throttles, stalls, and eventually your terminal just sits there.

What actually works is batching. Small batches, with pauses in between:

# Find all dataless files and force-download them in batches of 10
ls -laeOR . | rg "dataless" | awk '{print $NF}' | while read -r f; do
    cat "$f" > /dev/null 2>&1
    sleep 0.5
done

Even then, it's slow. Some batches of 50 would only result in 1 or 2 files actually downloading. I ended up running this repeatedly, checking the count each time, until all files were truly local. The .git/ directory alone took several passes.

---

The Permanent Workaround

Once I understood the problem, I set up a backup script that runs on a schedule and systematically forces downloads of all dataless files from my OneDrive, copying them to an external drive. It uses gtimeout (from coreutils) to prevent individual file downloads from hanging indefinitely, and quarantines files that repeatedly fail.

But the real lesson is simpler: don't run git from inside an OneDrive-synced folder if you can avoid it. Clone your repos to a local, non-synced directory for active development. Use OneDrive for storage and backup, not as your working directory.

If you must work from a synced folder (I still do, because I like having everything in one place), at minimum:

1. Pin your project folder. Right-click the folder in Finder, choose "Always Keep on This Device." This tells OneDrive to keep all files downloaded permanently.
2. Verify with ls -laeO. Don't trust Finder's cloud icons. Run the command and look for the dataless flag. If you see it, the file is a phantom.
3. Check .git/ separately. Pinning the project folder may not pin the hidden .git/ directory. Your source can be local while your Git history is still full of ghosts.
4. Use the /tmp clone workaround for commits. If Git hangs on mmap errors, clone your deploy repo to /tmp, copy your changed files in, and commit from there. I do this for every push on this blog.

---

The Irony

This blog post is saved in a OneDrive-synced folder. The .git repo for this site regularly has mmap issues. Every commit I make goes through a /tmp clone because I can't reliably run git commit from my working directory.

I know this is absurd. I do it anyway because having everything in one synced folder is worth the workaround. Just know what you're signing up for.

Footnote: If you're running a long backup transfer to an external drive (like I am, backing up everything off OneDrive onto a Seagate), disable macOS disk sleep so the drive doesn't spin down mid-transfer. Run sudo pmset -a disksleep 0 to keep it awake. You can re-enable it later with sudo pmset -a disksleep 10 (the default is 10 minutes).

---