After each PUT, check read the file's size from a HEAD and called anything
shorter a cut write. On 坚果云 every usage write failed that way with 0
bytes kept, three tries each; the 0 can only have come from the HEAD's
Content-Length, since a 6869-byte body that the PUT sends with its
Content-Length (not chunked) isn't cut by a dropping network three times
running. A HEAD that says short is now asked again of PROPFIND (Depth 0)
getcontentlength, the size WebDAV clients of 坚果云 read. The write counts
as kept when that size is whole. When PROPFIND gives no size, the HEAD's
stands. A real cut write is still told as cut, with the bytes PROPFIND
says were kept. The extra request is made only after a short HEAD, so
坚果云's request limit isn't spent on servers whose HEAD is right. The
backup's own PUT goes through the same check, so a 坚果云 user whose
setup changes would have hit the same error on the main sync.
Settings > Sync put "Couldn't share usage: …" in the same grey line as
"Synced · host", so it read as part of a sync that went fine. It is now a
line of its own under the status, in red, wrapped whole at 440px. The CLI
already printed it on its own line.
Verified: TestNutstoreHeadSaysNoLength and TestNutstoreBackupWrite use a
fake 坚果云: HEAD Content-Length: 0, real getcontentlength on PROPFIND,
409 for a read in a missing folder, a chunked PUT refused. Whole writes
sync with no usage error, and each write goes once with one HEAD and one
PROPFIND. A tunnel that keeps half is still told as cut, with the half it kept.
On the old dav.go all three fail ("the WebDAV server kept 0 of 536 bytes
of magpie.magpie-backup", "kept 0 of 6869"). TestDAVShortWrite and
TestUsageSharedShortWrite/TestUsageSyncShortWrite pass unchanged.
sync-usage-error.test.cjs runs in Chromium and WebKit, en/zh/ja/de, at
900 and 440px, and fails on the old app.js ("the status line carries no
usage error: 14:46 已同步 · dav.jianguoyun.com · 用量未能共享：…"). The
sync-*, s3-sync, usage-computers, gui-ja, gui-de, gui-zh-tw, i18n-keys
and click-scroll tests pass, 78/78. go test -tags nogui -count=1
./internal/davsync ./internal/gui pass under a temp HOME. go vet passes
on darwin, GOOS=linux and GOOS=windows. Not tried against a real 坚果云
account: that its HEAD answers 0 is inferred from the error, and that its
PROPFIND gives the real size is how its other WebDAV clients read sizes,
neither seen here.
yetone
10f7b4aa3f