-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Description
Description
WebDAV DELETE can hit PHP memory limit during trashbin move, leaving request aborted. The memory spike appears tied to folder size recalculation in cache updates during Trashbin::move2trash().
This surfaces in Ticket#9687404: deleting a tiny file via WebDAV consumed >500MB and the request died. The trash payload exists, but metadata/cache may be inconsistent. Related to #56493, but the root cause here is the memory‑OOM path, not just non‑atomic metadata ordering.
Steps to reproduce (likely)
- Use a user with a very large folder (many children) in home storage.
- Delete a file from that folder via WebDAV/UI (trashbin enabled).
- Observe PHP memory growth during
Trashbin::move2trash().
Actual result
- WebDAV DELETE hits memory limit (PHP fatal), request aborts.
- Inconsistent trash state possible: payload moved but DB/cache incomplete.
Expected result
- Trash move should not require full folder scan or excessive memory.
- Delete should be robust even on large folders.
Analysis / suspected root cause
During trash move, cache updater calls renameFromStorage() which triggers Cache::correctFolderSize() for source and target. That calls calculateFolderSizeInner() and fetchAll() on child entries (large folders) which can blow memory.
Relevant paths:
apps/files_trashbin/lib/Trashbin.php→move2trash()→Updater::renameFromStorage()/update()lib/private/Files/Cache/Updater.php→copyOrRenameFromStorage()→Cache::correctFolderSize()lib/private/Files/Cache/Cache.php→calculateFolderSizeInner()(fetchAll())
Proposed direction
- Add a fast path for trash moves to avoid full folder size recalculation; use known size delta to update parent sizes, or defer size correction to background.
- Alternatively: add optional size‑delta parameter to
renameFromStorage()and skipcorrectFolderSize()when provided.
Notes
PR #57360 mitigates orphaned metadata by inserting files_trash row before payload move, but does not fix memory‑OOM path.