-
If I upload A, B, C, D, E. and delete ABCD, left E. Is my daily usage A+B+C+D+E or just E?
-
Same case, with editable link. Does it use same mechanism as normal upload? If I upload A, B, C, D, E. and delete ABCD, left E. Is my daily usage A+B+C+D+E or just E?
The reason I ask is because I am planning a feature of "cloud sync" link, which saving frequency matters. If it's sum up total, frequent saving "just to feel safe" will exhaust quota too soon.
Here's AI helper verdict, I think it makes sense. But from economic (which I knows little), "just E" isn't too far fetch. I just wanna make sure before making harder restriction.
Verdict Q1 (normal upload, delete 4, keep 1): A+B+C+D+E (sum). Deletion does not refund the daily allowance. The quota is a throughput/ingress counter for the day; deleting a file frees disk but gives nothing back. The docs' deletion section never mentions a refund — and no upload service refunds on delete. So 5 distinct uploads = full sum charged, regardless of what you delete afterward.
Q2 (editable, overwrite 5×, left with last): same mechanism → also A+B+C+D+E. The docs explicitly state: "Editable writes use the normal anonymous upload quota." Same bucket, same non-refundable accounting. Each distinct set uploads a new payload and is metered like a normal upload; the old content being cleared is just cleanup, not a credit. The identical-text no-op is the only free case — and it's not a special favor, it's plain content-dedup (same hash already stored = nothing new to ingest), the same thing your normal-upload-dedup claim predicts.
The one honest gap: "deletion doesn't refund" is documented-by-omission for normal uploads (universal behavior, doc never says otherwise), and the editable↔normal linkage is doc-stated — so the editable-no-refund step is an inference, but a very safe one.
Implication for your cloud-sync feature Yes — your fear is correct. Frequent full-content saves "just to feel safe" will blow the daily quota fast. Math: anonymous ~30MB/day; if each save re-sends the full current content, a 1MB doc saved 30× = quota gone. The 10s rate limit does NOT save you (it caps frequency, not bytes).
Mitigations, in order of impact:
Dirty-check before every save — never call set unless content actually changed since last successful write. Unchanged content is free anyway (dedup), but doing the check client-side avoids even the round-trip. This alone kills the "save to feel safe" waste. Debounce, don't autosave-on-keystroke — save after ~5s of idle (or on blur/unload), not every keystroke. The 10s commit limit makes sub-10s saves pointless anyway. Compress — the docs themselves note ~10x via CompressionStream/pako. 1MB→~100KB makes 30 saves ≈ 3MB, survivable. expires ≤24h only if the sync data is genuinely throwaway — gives 400× quota, but the file may vanish after expiry. Don't use for real cloud sync. If content grows large, full-rewrite-per-save is fundamentally capped — at that point you'd need chunked/diff storage, which editable.set (wholesale replace) doesn't natively support; you'd manage a patch format yourself. Bottom line: design the save loop around dirty-check + debounce + compression. Under that, "saving frequently to feel safe" becomes nearly free because most fires hit the dirty-check (or the dedup no-op) and cost nothing.