[QA] Part files are not considered for quota while they are uploaded

[jnweiger]

Seen while testing #39895 with 10.11.0-beta.1

The initial description for this PR has
"

• Part files will also be considered for quota while they're being
  uploaded
  "

I believe this part of the PR was not implemented:

User2 has 40 MB quota. He has 5.4 MB already, and is uploading a 33 MB file (with chunks of 10 MB).
The used quota remains at 5.4 MB until the very last moment, when the file is assembled.

---

---

Similarly, when the uploading a 9.5 MB file (no chunking, directly into the target directory with a *.part file) the quota does not see the *.part file. Only after assembly, it jumps up.

Expected behaviour:

• Quota used also counts part files and chunks.

Everything else in #39895 seems to work fine.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed.

[jvillafanez]

I'm not sure if we can anything... I think the part storage doesn't count for the quota, and maybe it shouldn't count: even if you don't have enough quota for the file, the file could end up in an external storage where quota doesn't apply.

The only thing we can discuss is whether we should remove the chunks or not right after the failed upload. Removing the chunks make sense, but clients might retry the upload later just uploading the missing chunks (not sure if it's possible or not)

[jvillafanez]

The only thing we can discuss is whether we should remove the chunks or not right after the failed upload. Removing the chunks make sense, but clients might retry the upload later just uploading the missing chunks (not sure if it's possible or not)

Likely related #40892

[DeepDiver1975]

🤖 Automated issue triage by Claude Code review agent.

I looked into the quota-enforcement path to ground this report.

The observation is accurate — there is a real window where used quota does not reflect in-flight upload data:

• OC\Files\Storage\Wrapper\Quota::free_space() (lib/private/Files/Storage/Wrapper/Quota.php:87-106) computes used space from the cache entry of sizeRoot (getSize(), lines 67-79). That cache reflects the assembled files/ tree, not the temporary .part file or the per-chunk upload-temp files, so neither is included in the "used" figure until assembly completes.
• fopen() (lines 147-179) does wrap each write stream in OC\Files\Stream\Quota with a per-stream $free cap, and it adds back the size of a file being overwritten (lines 152-171) — but because $free is recomputed from the cached used-size, concurrent/sequential in-flight part files don't subtract from each other. The net effect is exactly what was reported: a 33 MB chunked upload (or a 9.5 MB .part upload) doesn't move the "used" gauge until the final assembly, so quota can be temporarily exceeded mid-upload.

Why this is a guidance question rather than a straightforward fix: as @jvillafanez noted in this thread, making part/chunk files count against quota is a deliberate design choice, not obviously correct. Legitimate reasons not to count them:

• The upload's final destination may be external storage / S3 where the local quota doesn't apply at all — pre-charging quota against a .part file would wrongly reject valid uploads (cf. the part-file-cleanup work in fix: remove just uploaded files in case of error - also for storages … #40892).
• Chunked-upload retry semantics: clients may resume by re-uploading only missing chunks, so eagerly counting (and the matching question of when to evict) interacts with the chunk lifecycle.
• The final assembled size is validated, so the over-quota state is transient, not a persisted bypass.

So the decisions that need a product/owner call are:

1. Should in-flight .part/chunk files count toward quota at all (accepting the external-storage caveat), or is the current "validate at assembly" behaviour the intended contract?
2. If they should count, how should chunk cleanup/retry and external-storage targets be handled?

@DeepDiver1975 could you confirm the intended behaviour here? That determines whether this is a fix (count part files + handle the storage/retry edge cases) or a documented works-as-intended. (No CODEOWNERS file is present in the repo, so mentioning the configured fallback owner.)

[dj4oC]

Before this can be acted on, the following needs to be resolved:

• Product decision required: should in-flight .part/chunk upload files count toward quota at all? Verified in lib/private/Files/Storage/Wrapper/Quota.php that "used" space is computed from the cache's assembled-tree size, so quota is only enforced at final assembly, not during upload — this is a deliberate-looking gap, not an obvious bug, since the upload's eventual destination may be external storage where local quota doesn't apply.
• If part/chunk files should count, a second decision is needed on how that interacts with chunked-upload retry (clients may resume by re-uploading only missing chunks) and with external-storage targets where quota may not be meaningful.
• Related: whether chunks should be actively cleaned up after a failed/over-quota upload (see the linked fix: remove just uploaded files in case of error - also for storages … #40892 chunk-cleanup work) is a separate but connected decision.

🤖 Automated by Claude Code

---

Generated by Claude Code