4.1 KiB
4.1 KiB
Trash Feature Implementation Summary
This document summarizes the implementation of the trash/recycle bin feature in OxiCloud.
Architecture Overview
The trash feature is implemented following the hexagonal architecture (clean architecture) principles of OxiCloud:
-
Domain Layer (
/src/domain/):- Entities:
TrashedItemrepresenting files and folders in the trash bin - Repository interfaces:
TrashRepositorydefining operations for trash management
- Entities:
-
Application Layer (
/src/application/):- DTOs:
TrashedItemDtofor data transfer between layers - Ports:
TrashUseCasedefining the operations available to clients - Services:
TrashServiceimplementing the trash use cases
- DTOs:
-
Infrastructure Layer (
/src/infrastructure/):- Repositories:
TrashFsRepositoryfor filesystem-based trash storage - Extensions to existing repositories:
FileRepositoryTrashandFolderRepositoryTrash - Services:
TrashCleanupServicefor automatic cleanup of expired trash items
- Repositories:
-
Interface Layer (
/src/interfaces/):- API handlers:
trash_handler.rsproviding HTTP endpoints for trash operations - Routes: Updated
routes.rsto include trash-related endpoints
- API handlers:
Key Features
- Soft Deletion: Moving files and folders to trash instead of immediate permanent deletion
- Per-User Trash: Each user has their own isolated trash bin
- Retention Policy: Items are automatically deleted after a configurable time period
- Restoration: Items can be restored to their original location
- Permanent Deletion: Items can be permanently deleted before the retention period expires
- Empty Trash: All items in the trash can be permanently deleted at once
API Endpoints
The trash feature exposes the following REST API endpoints:
GET /api/trash: List all items in the user's trash binDELETE /api/files/trash/:file_id: Move a file to trashDELETE /api/folders/trash/:folder_id: Move a folder to trashPOST /api/trash/:trash_id/restore: Restore an item from trash to its original locationDELETE /api/trash/:trash_id: Permanently delete an item from trashDELETE /api/trash/empty: Empty the entire trash bin
Testing
The trash feature includes comprehensive testing:
-
Unit Tests: Testing the
TrashServiceapplication service- Test moving files and folders to trash
- Test restoring items from trash
- Test permanent deletion
- Test empty trash operation
-
Integration Tests: Python script to test the API endpoints
- End-to-end testing of all trash operations
- Verification of proper behavior for moving, listing, restoring, and deleting
-
Shell Script: For manual testing and demonstration
- Individual tests for each operation
- Visual feedback of successful operations
Configuration
The trash feature can be configured via environment variables:
TRASH_ENABLED: Enable/disable the trash feature (default: true)TRASH_RETENTION_DAYS: Number of days to keep items in trash before automatic deletion (default: 30)
Implementation Details
- Physical File Storage: When items are moved to trash, they are physically moved to a
.trashdirectory - Metadata Storage: Information about trashed items is stored in a separate database table or file
- User Isolation: Trash items are isolated by user ID to prevent access to other users' trash
- Automatic Cleanup: A background job runs periodically to clean up expired trash items
- Transaction Safety: Operations are designed to be atomic and safe, with proper error handling
Future Enhancements
Potential improvements for the trash feature:
- Trash Quotas: Limit the amount of storage a user can use for trash
- Batch Operations: Add support for trashing, restoring, or deleting multiple items at once
- Storage Optimization: Implement deduplication for trashed items to save storage space
- Version Control: Keep track of file versions when moving to trash
- Scheduled Cleanup: Allow users to configure custom retention periods
- Trash Monitoring: Add metrics and alerts for trash usage and cleanup operations