Filebrowser: Recycle Bin

Add a central management spot for restoring or finally deleting files and folders.

Recommended setup

1. Enable bucket versioning on the storage bucket.

2. On delete, create an app-level trash record and optionally a delete marker by deleting the current version.

3. Keep noncurrent versions for a fixed retention window with lifecycle rules.

4. Optionally move older trash data to cheaper storage classes before final purge, if restore speed requirements allow it.

5. Periodically purge expired trash and monitor noncurrent-version bytes with Storage Lens.

When this becomes expensive

It gets costly when your objects are large, deletions are frequent, and retention is long. It also gets expensive when users repeatedly overwrite the same keys, because every overwrite creates another billable version unless you expire old ones. If you replicate versions for disaster recovery, multiply that storage footprint across regions.

Start by locating the Filebrowser entry point and the existing storage deletion flow; the issue names no files or tests. Compare the implementation with the versioning, trash-record, retention, lifecycle, and purge requirements, and consider the work done only when restore, permanent deletion, retention, and monitoring behavior are defined and covered.