The site drive is WebDAV not a disk

What you'll see

A shell command against a Docly site mapped to a drive letter fails with Working directory "L:\…" was deleted, MODULE_NOT_FOUND, or a write that reports the wrong byte count. You open the folder in Explorer and it is obviously fine. Retrying the same command works. The natural conclusion — "the network drive is down" — is wrong, and it sends you chasing a problem that does not exist.

What's actually happening

The drive is not a disk, and it is not down. Check what it actually is:

net use

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
             L:        \\docly.net@SSL\drive     Web Client Network

Web Client Network means WebDAV over HTTPS, served by Windows' WebClient service. It is not SMB and not local storage. Every path operation — every cd, every stat, every directory listing — is an HTTP request over TLS to a remote server. A "file read" is a network round trip that can be slow, throttled, or momentarily fail, exactly like any other HTTP call.

That changes what an error means. When a shell sets its working directory it validates the path first. If that validation is a WebDAV request and the request hiccups, the shell gets "cannot access" back and reports the only thing it can conclude: the directory is gone. The message says deleted; the reality is one HTTP call timed out.

Why Explorer disagrees with you

Explorer is built for exactly this. It caches directory listings aggressively, retries silently, and keeps a warm WebClient session alive. So while a shell is failing every third command, Explorer shows a healthy folder — and you conclude the shell is lying or the drive is flapping. Neither is true. Explorer's opinion is not evidence about the drive's state, because Explorer is hiding the very failures you are trying to diagnose.

The failure modes this produces

• "Working directory was deleted." The most common. Transient; retrying works. Do not interpret it as a real filesystem event.
• Write verification mismatches. A tool writes a file, reads back the size, and sees the previous length — the WebClient cache had not caught up. The write usually succeeded. Verify by reading the content back, not by trusting the reported size.
• Stale reads right after a write. Same cause. If a just-written file looks unchanged, re-read before concluding the write failed.
• Latency, not bandwidth. Thousands of small operations (a recursive grep, a big glob) are far worse than one large file read, because each one is a round trip. This is why whole-tree searches can take 20+ seconds or time out.

None of these mean the drive is broken. They mean you are doing filesystem operations over HTTP and should expect HTTP's failure modes.

What to do

Diagnose it once, then stop re-diagnosing it

Run net use. If the drive says Web Client Network, every "disk error" you see for the rest of the session has this explanation. Do not spend time on it again — and specifically, do not tell your colleague the drive is down. It is not.

The 60-second negative cache — why retrying immediately does not work

Check the WebClient parameters:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters"

ServerNotFoundCacheLifeTimeInSec : 60
InternetServerTimeoutInSec       : 30
SendReceiveTimeoutInSec          : 60
FileSizeLimitInBytes             : 50000000

ServerNotFoundCacheLifeTimeInSec: 60 is the one that matters. When WebClient fails to reach a path once, Windows caches "not found" for 60 seconds and answers every subsequent request from that cache without contacting the server. One transient hiccup becomes a full minute of failures.

This inverts the obvious advice. Hammering retries inside that window is guaranteed to fail — you are being answered by a cache, not by the server. On dops.no, five consecutive retries all failed and the same command succeeded minutes later. That is not bad luck; that is the negative cache expiring.

So: retry, but expect to wait. One retry is worth trying — the failure may have been the request itself rather than a cached verdict. If two quick retries fail, you are probably inside the window: do something else and come back. A retry loop is wasted effort.

Caveat, stated plainly: the registry values and the observed behaviour match well, but this has not been proven by a controlled before/after test. It is a well-evidenced hypothesis, not an established fact.

A possible real fix (admin, and it is a system setting)

Setting the negative cache to zero should turn a transient failure back into a single failure instead of sixty seconds of them:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" -Name ServerNotFoundCacheLifeTimeInSec -Value 0
Restart-Service WebClient

This is a machine-level change to a system service. It belongs to whoever owns the machine — an agent should surface it, not perform it.

What you must not do while it is failing

This matters far more than the retry strategy:

• Do not switch to a more dangerous tool because the safe one is flaky. This is the real damage. A file-editing tool fails twice on WebDAV, so you reach for node -e "…replace…" to force it through — and now you are hand-escaping JavaScript through shell → node → string → regex. On dops.no exactly this lost one backslash, broke boot.js, and took a live site's JavaScript down for 40 minutes. The flaky mount did not cause that outage; the workaround did.
  The failure mode is not hypothetical or rare: while writing this very article, a node -e edit silently ate the backslashes out of the registry paths above, publishing HKLM:SYSTEMCurrentControlSetServices. Same bug, same day, in the text warning about the bug. Use a file-editing tool.
• Do not conclude a write failed because verification says so. The mount reports normalised sizes, so "Write verification failed" is almost always a false alarm. Read the content back to check.
• Do not blindly re-run a non-idempotent write. If a verification mismatch makes you re-issue an append or an insert, you can apply the change twice. Read first, then decide.

Work with the latency, not against it

• Prefer few large operations over many small ones. One readFileSync of a big file beats a recursive glob over a tree. Every path touch is an HTTP request.
• Scope searches narrowly. A repo-wide grep across a WebDAV mount will crawl or time out. Search a folder, not the site root.
• Keep scratch and temp files off the mount. Write intermediate output, JSON dumps and measurement data to local disk. Only files that must live on the site belong on the site.
• Read once, work in memory, write once. Especially when assembling .docly JSON: read the inputs, build the object in memory, write the result in a single call.
• File-reading and file-editing tools often keep working when the shell will not. The shell validates its working directory on every command and is therefore the most exposed. If the shell is stuck, the editing tools may not be.

If it is failing constantly rather than occasionally

1. Confirm the mount still exists: net use.
2. Check the WebClient service is running — it stops on idle on some configurations: Get-Service WebClient.
3. Remount: net use L: /delete, then map it again.
4. Open the folder in Explorer once — it warms the WebClient session, which genuinely helps a cold mount.

What this means for AI agents

An agent will interpret "directory was deleted" literally, report to the user that the disk is down, and either stall or improvise a workaround. Both are wrong. Give an agent working on a Docly mount this rule:

On the site drive, a filesystem error is an HTTP hiccup until proven otherwise. Retry once with the same tool; if it keeps failing you are likely inside a 60-second negative cache, so wait rather than loop. Never switch to shell-escaped JavaScript to force an edit through, and never report a WebDAV timeout as data loss.

See also Work safely on a live site (the outage described above, and why the workaround is the dangerous part), Use a scratch hash file to test Docly functions, and Creating new docly files.