False write-verification failures on the WebDAV drive

What you'll see

An AI coding agent or editor writing files to a WebDAV-mapped Docly drive (L:) reports a write failure of the form:

Write verification failed: <file> is 11855 bytes on disk, expected 11862

It happens on every edit, deterministically rather than randomly. The file in Docly is actually correct — opening or re-reading it shows the new content. The message comes from the client's own post-write size check (for example Claude Code's), not from Docly.

What's actually happening

The two numbers are the old and new file sizes, not a corrupted write. 11855 is the size of the previous version of the file; 11862 is the new one. The difference (here, 7 bytes) is simply how much that particular edit grew the file. It is not a mis-serialised version of the new content.

The content round-trip does not lose bytes. Docly stores the written text verbatim and returns Encoding.UTF8.GetBytes(content) on GET, so for valid UTF-8 without a BOM the byte count that comes back is exactly what was PUT. A genuine round-trip cannot drop 7 bytes. (The only content-level exception is a UTF-8 BOM being stripped — and that is 3 bytes, not 7, and agents normally write without a BOM.) So the mismatch is a stale reported size, never lost data.

Root cause: the MRxDAV metadata cache

Windows' built-in WebDAV client (the WebClient service / MRxDAV redirector) caches file metadata — including size — on a purely time-based schedule, not via HTTP cache semantics. The relevant parameters live under HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters (and mirror keys under MRxDAV\Parameters):

FileInformationCacheLifeTimeInSec : 60        # how long file info (incl. size) is cached before re-fetch
FileNotFoundCacheLifeTimeInSec    : 60        # how long "not found" is cached
FileAttributesLimitInBytes        : 1000000   # max total attribute/PROPFIND size per folder

For up to 60 seconds after the redirector has learned a file's size, it will answer a stat from that cache without asking the server. When the client writes the file and immediately stats it, it can read the pre-write size straight from the cache and conclude the write failed.

Why it fails every time, not just occasionally

The metadata cache is populated by read / PROPFIND operations (for example a directory listing before an edit), not necessarily refreshed by the redirector's own PUT. So the sequence write → immediate stat reads the previously-cached size from the last listing and fails deterministically. A pure 60-second timeout would let some writes succeed after an idle period; "every edit fails" fits a cache that is re-filled by a listing before each edit.

Why server-side headers do not fix it

Docly already returns a fresh ETag built from (Modified, Filesize) and Cache-Control: no-cache, must-revalidate on Drive responses, and maintains Document.Filesize so that the ETag and getcontentlength always report the same, current number. But the redirector's metadata cache is time-based and does not ETag-revalidate cached metadata. no-cache governs the HTTP content cache (the GET body), not MRxDAV's FileInformation cache. No server-side change can invalidate this client cache — the fix has to be client-side.

What to do

Do not treat it as data loss

The write almost certainly succeeded. Confirm by reading the file's content back (not its reported size). Do not re-run the write in a panic, and above all do not switch to a more dangerous tool (shell-escaped node -e, hand-built writes) to "force it through" — that is how false verification failures turn into real outages. See The site drive is WebDAV not a disk.

Re-writing is safe (no doubling)

Docly's PUT is a full overwrite (the document's content is replaced, not appended). A client that re-PUTs the whole file — as Claude Code's Write/Edit does — simply stores the same complete content again, so there is no risk of the change being applied twice. The doubling risk only applies to tools that do append/delta writes against a write they believe failed.

The reliable fix (client-side, admin, system setting)

Disable the metadata cache on the machine running the agent so every stat hits the server:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" -Name FileInformationCacheLifeTimeInSec -Value 0
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters" -Name FileNotFoundCacheLifeTimeInSec -Value 0

net stop WebClient
net start WebClient

This is a machine-level change to a system service, not a Docly code change. It belongs to whoever owns the machine — an agent should surface it, not perform it. Setting FileNotFoundCacheLifeTimeInSec to 0 as well is optional but removes the related 60-second negative-cache behaviour described in the companion article.

What does not work

• Server-side header tweaks. no-cache/ETag on Drive responses cannot invalidate the redirector's metadata cache, because it does not ETag-revalidate metadata. Low cost, but no effect.
• Waiting out the timeout mid-session. Because a directory listing re-fills the cache before each edit, idling does not reliably clear the stale size for the next write.

Rule of thumb for agents

"Write verification failed: is N bytes, expected M" on a Docly WebDAV mount is a false alarm from the client's own size check. N is the old size, M is the new one; the write succeeded and Docly round-trips bytes exactly. Confirm by reading the content back, never report it as data loss, and never re-PUT into a more dangerous tool. The real fix is FileInformationCacheLifeTimeInSec=0 on the client machine.

See also The site drive is WebDAV not a disk and Creating new docly files.