Three attempts at one check: reparse points, OneDrive and the desktop
A one-line safety check took three releases to get right, and two of the attempts caused regressions worse than the problem being fixed.
This is a small story about a small check, and it is here because it is the clearest example in this product of a fix causing worse damage than the bug.
The setup#
Following the rule from The same bug, five times: offline network locations — never touch the file system from the interface thread — DeskDrawer needs to know whether a desktop item might live somewhere slow, so it can route that work to a background thread.
The obvious way to ask is a straightforward Windows call for the item's attributes. That works, until the item is a Cloud placeholder: asking that particular question about an online-only OneDrive file can force it to download. Now browsing your desktop pulls files out of the cloud, which is exactly what "files on demand" exists to prevent.
Attempt one replaced the attribute call with a directory-enumeration call that returns the same information without hydrating the file. Correct.
Attempt two: too broad#
The same work introduced a check for reparse points — the Windows mechanism behind junctions and symbolic links — because a redirect can point at a network location, and that is precisely the slow case worth avoiding.
The check flagged any reparse point.
This broke something specific and common: a Desktop folder that OneDrive has backed up is itself a redirect. Flagging it as potentially remote meant DeskDrawer stopped attaching its live file-system watcher to it. For anyone with OneDrive desktop backup — a large share of Windows users — the desktop silently stopped updating. Create a file, nothing appears until a manual refresh.
Attempt three narrowed the check to name-surrogate reparse points, the subclass that actually represents a directory redirect, which restored the watcher.
Attempt three: still wrong, in the other direction#
Narrowing fixed the OneDrive case and introduced two new ones, both shipped and both found in the next audit round.
The remaining error was conceptual. The check still conflated two different questions:
- Is this item a redirect?
- Does this item's redirect point somewhere slow?
A junction to a folder on the same physical disk answers yes to the first and no to the second. It is local, it is fast, and it wants the ordinary code path with a live watcher — but it was still being treated as suspect. The consequences:
- A cancelled move onto a local junction dropped the item's Board membership, so an icon disappeared from its board after an operation the user had cancelled.
- A Desktop folder reached through a local junction — the standard arrangement when a user profile has been moved to another drive — lost its watcher again, for a different reason than before.
What finally worked#
Stop inferring from the presence of a redirect and read the redirect target.
DeskDrawer now opens the reparse point without following it, reads the reparse data, extracts the actual target path, and classifies on that. A name-surrogate reparse point whose target is local is treated as local. Only one whose target is genuinely remote takes the careful path.
That shipped in 1.2.5, and it is the version that answers the right question. The first two attempts were answering a proxy question that happened to correlate with the right one most of the time.
The lesson#
Both regressions came from a fix, not from original code. Both were introduced while making the product more correct. And the second one was introduced by the fix for the first.
The general shape:
When a safety check uses a proxy for the property you care about, it will be wrong for every case where the proxy and the property come apart — and those cases are, by construction, the ones you did not think of.
"Is it a reparse point" was a proxy for "is it slow". A local junction is exactly where those two diverge, and a local junction is not exotic — it is what you get when Windows moves a user profile.
The wider pattern of fixes introducing regressions is in Eight rounds of code audits on a small app, and what each one found.