Spacedrive DeleteJob 策略模式改造本地、云端与跨设备远程删除的完整实现指南【免费下载链接】spacedriveSpacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.项目地址: https://gitcode.com/gh_mirrors/sp/spacedrive导读本文围绕 Spacedrive 核心任务 FSYNC-001 展开完整讲解如何将DeleteJob从仅支持本地删除升级为基于**策略模式Strategy Pattern**的统一删除架构使其与FileCopyJob保持同构并具备跨设备远程删除、云端存储VolumeBackend删除两种全新能力。读完本文你将掌握 Spacedrive 文件删除模块的完整调用链——从DeleteStrategy特征定义、DeleteStrategyRouter路由选择、三种删除模式Trash / Permanent / Secure的实现细节到基于 P2P 网络的file_delete协议与路径白名单安全校验以及对应的 9 个集成测试的验证逻辑。背景与问题为什么 DeleteJob 需要策略模式在 Spacedrive 的 File Sync 体系中**Mirror镜像与Bidirectional双向**两种同步模式要求删除操作能够被派发到远端设备。改造前的DeleteJob存在三个核心短板缺少策略模式路由逻辑而FileCopyJob早已实现了CopyStrategy策略体系见 core/src/ops/files/copy/strategy.rs删除侧架构落后于复制侧不具备跨设备删除能力无法在远端设备上执行删除与其它文件操作架构不一致不利于统一维护与测试。该任务的目标状态非常明确DeleteJob使用策略模式同时具备本地Local与远程Remote两种策略最终让 File Sync 能跨设备派发删除操作。从实现完成度看该任务已全部落地任务文档status: Donestrategy.rs约 350 行、routing.rs约 50 行、网络协议处理器file_delete.rs约 250 行以及delete_strategy_test.rs中 9 个全部通过的集成测试。下文将按实现顺序逐层拆解。一、DeleteStrategy 特征删除操作的统一抽象策略模式的核心是抽象出执行删除这一行为让调用方无需关心具体删除发生在本地、云端还是远端设备。该特征定义在 core/src/ops/files/delete/strategy.rs#[async_trait] pub trait DeleteStrategy: Send Sync { /// Execute deletion of paths async fn execute( self, ctx: JobContext_, paths: [SdPath], mode: DeleteMode, ) - ResultVecDeleteResult; }要点解析Send Sync约束保证策略实例可以跨异步任务边界安全共享这是 Job 系统并发执行的基础paths: [SdPath]一次批量处理多个目标路径而非单路径逐条调用为后续按设备分组的远程删除提供接口基础DeleteMode来自job.rs的删除模式枚举决定删除语义返回值VecDeleteResult每个路径独立返回结果失败不中断整批操作。配套的DeleteResult结构体记录了单路径的完整删除结果#[derive(Debug, Clone, Serialize, Deserialize)] pub struct DeleteResult { pub path: SdPath, pub success: bool, pub bytes_freed: u64, pub error: OptionString, }其中bytes_freed用于汇总统计对应DeleteOutput.total_byteserror携带失败原因便于上层聚合为DeleteError列表。DeleteMode 的三种语义core/src/ops/files/delete/job.rs 中定义了删除模式枚举这也是整个删除模块的行为分水岭pub enum DeleteMode { /// Move to trash/recycle bin Trash, /// Permanent deletion (cannot be undone) Permanent, /// Secure deletion (overwrite data) Secure, }三者的差异直接映射到LocalDeleteStrategy的三个方法详见下一节模式语义底层操作可恢复性Trash移入系统回收站/废纸篓trashcrate 原生调用可恢复Permanent永久删除不可撤销tokio::fs::remove_file/remove_dir_all不可恢复Secure安全删除覆写数据后删除3 遍随机数据覆写 删除不可恢复且防恢复二、LocalDeleteStrategy本地与云端删除的实现LocalDeleteStrategy是策略模式下的主力选手它同时承担了本地物理路径删除与云路径删除两种职责任务文档进度中明确云路径通过 VolumeBackend 整合进本地策略无需单独的 CloudDeleteStrategy。2.1 统一入口 execute()execute()根据路径类型分派到三条路径见 strategy.rslet result match path { // Local physical path - use direct filesystem (fast path) _ if path.is_local() { let local_path path.as_local_path()...?; let size self.get_path_size(local_path).await.unwrap_or(0); let deletion_result match mode { DeleteMode::Trash self.move_to_trash(local_path).await, DeleteMode::Permanent self.permanent_delete(local_path).await, DeleteMode::Secure self.secure_delete(local_path).await, }; ... } // Cloud path - use VolumeBackend _ if path.is_cloud() self.delete_cloud_path(ctx, path, mode.clone()).await, // Remote physical or content paths not supported _ DeleteResult { success: false, error: Some(Path is remote or unsupported) }, };值得注意的是删除前会先通过get_path_size()计算路径大小文件或目录的迭代式求和用于填充bytes_freed指标。2.2 move_to_trash原生回收站支持#[cfg(any(target_os windows, target_os macos, target_os linux))] pub async fn move_to_trash(self, path: Path) - Result(), std::io::Error { let path path.to_path_buf(); tokio::task::spawn_blocking(move || { trash::delete(path).map_err(...) }).await??; Ok(()) }三个关键设计使用trashcrate 获得原生平台语义Windows 走SHFileOperation进回收站、macOS 走NSFileManager进废纸篓、Linux 遵循 XDG trash 规范spawn_blocking将阻塞式系统调用移出异步运行时避免阻塞 Tokio 工作线程通过cfg属性对非主流平台提供降级实现返回Unsupported错误——这正是任务进度中提到的macOS cfg attributes 平台适配修复。2.3 permanent_delete直接删除pub async fn permanent_delete(self, path: Path) - Result(), std::io::Error { let metadata fs::metadata(path).await?; if metadata.is_file() { fs::remove_file(path).await?; } else if metadata.is_dir() { fs::remove_dir_all(path).await?; } Ok(()) }语义清晰文件走remove_file目录递归走remove_dir_all全程使用tokio::fs异步 API 保持非阻塞。2.4 secure_delete3 遍随机覆写安全删除是三种模式中唯一的防数据恢复实现其核心是secure_overwrite_file// Overwrite with random data (3 passes) for _ in 0..3 { file.seek(std::io::SeekFrom::Start(0)).await?; let mut remaining size; while remaining 0 { let chunk_size std::cmp::min(remaining, 64 * 1024) as usize; let buffer { let mut rng rand::thread_rng(); let mut buf vec![0u8; chunk_size]; rng.fill_bytes(mut buf); buf }; file.write_all(buffer).await?; remaining - chunk_size as u64; } file.flush().await?; file.sync_all().await?; }设计要点3 遍覆写 每次sync_all落盘确保随机数据真正写入物理介质而不是停留在页缓存64 KiB 分块避免一次性分配大缓冲区适配大文件场景目录递归安全删除secure_delete_directory用显式栈迭代遍历而非递归函数先对每个文件执行覆写删除最后remove_dir_all清空目录结构覆写完成后仍调用remove_file/remove_dir_all释放目录项。2.5 delete_cloud_path云路径删除VolumeBackend 集成云路径无法用本地文件系统 API 处理因此LocalDeleteStrategy通过VolumeBackend抽象层完成删除。delete_cloud_path的完整调用链为模式限制云路径仅支持Permanent模式Trash/Secure 会返回明确错误Delete mode X not supported for cloud paths (only Permanent)获取 VolumeManager通过ctx.volume_manager()拿到卷管理器缺失则返回失败解析云路径path.as_cloud()拆出(service, identifier, cloud_path)三元组查找云卷volume_manager.find_cloud_volume(service, identifier)定位对应Volume获取后端从volume.backend取得VolumeBackend实例删除前取大小backend.metadata(cloud_path)尽力获取大小失败则记为 0不阻断删除执行删除backend.delete(Path::new(cloud_path))。而VolumeBackend特征本身定义在 core/src/volume/backend/mod.rs其中与删除直接相关的方法为/// Delete file or directory async fn delete(self, path: Path) - Result(), VolumeError;从源码结构看该特征由两个后端实现LocalBackend包装tokio::fs操作负责本地卷CloudBackend基于 OpenDALdelete()映射到 OpenDAL 的 delete/remove_all 语义负责 S3、GoogleDrive、Dropbox、OneDrive、GCS 等云服务CloudServiceType枚举即列于 backend/mod.rs。这一设计让云路径删除与本地路径删除在策略层面统一路由器无需感知底层存储差异。三、RemoteDeleteStrategy跨设备远程删除RemoteDeleteStrategy负责处理包含远端路径的删除请求其执行逻辑分两步strategy.rs3.1 按目标设备分组let mut by_device: HashMapUuid, VecSdPath HashMap::new(); for path in paths { if let Some(device_id) path.device_id() { by_device.entry(device_id).or_default().push(path.clone()); } }每个SdPath携带设备标识device_id()策略先按设备聚合路径一台设备只建立一次网络请求避免 N 条路径产生 N 次连接。3.2 逐设备发送删除请求delete_on_device的请求发送流程从ctx.networking_service()获取网络服务生成request_id Uuid::new_v4()关联请求与响应构造FileDeleteMessage::Request { paths, mode, request_id }用rmp_serdeMessagePack序列化载荷对小型消息体压缩友好通过networking.send_message(device_id, file_delete, request_data)发送记录日志后返回。需要注意的实现现状源码中delete_on_device目前返回的是乐观结果success: truebytes_freed: 0代码注释明确标注// TODO: Implement proper request/response pattern // For now, return optimistic results // In production, we need to wait for response from remote device即发送成功后暂不等待远端确认属于任务文档中Request/response pattern with timeout handling规划的待完善部分。这一点必须如实告知读者避免误解为已实现完整同步确认。3.3 网络协议FileDeleteMessage远程删除的协议载荷定义在 strategy.rs#[derive(Debug, Clone, Serialize, Deserialize)] pub enum FileDeleteMessage { Request { paths: VecSdPath, mode: DeleteMode, request_id: Uuid, }, Response { request_id: Uuid, results: VecDeleteResult, }, }Request携带待删路径、模式与请求 IDResponse以request_id回关联到对应请求并携带逐路径的DeleteResult数组。四、DeleteStrategyRouter路由决策路由器是策略模式中的决策者实现在 core/src/ops/files/delete/routing.rspub struct DeleteStrategyRouter; impl DeleteStrategyRouter { pub async fn select_strategy( paths: [SdPath], _volume_manager: OptionVolumeManager, ) - Boxdyn DeleteStrategy { let all_local paths.iter().all(|p| p.is_local()); if all_local { Box::new(LocalDeleteStrategy) } else { Box::new(RemoteDeleteStrategy) } } }路由规则极简且明确所有路径均为本地is_local()→ LocalDeleteStrategy只要存在一条非本地路径 → RemoteDeleteStrategy由远程设备各自执行本地删除因此云端路径在路由器层面并不需要特殊分支。配套的describe_strategy提供人类可读的策略描述用于日志与调试路径构成描述输出全部本地Local deletion全部远程Remote deletion (N devices)N 为去重后的设备数本地 远程混合Mixed deletion (M local, N remote)五、DeleteJob 重构从 400 行到 70 行核心逻辑任务文档进度显示重构后DeleteJob核心逻辑从约 400 行缩减到约 70 行这正是策略模式把实现细节下沉到策略类的直接收益。当前 job.rs 中run()的流程为模式标记与安全校验Permanent/Secure模式必须显式确认confirm_permanent为false时直接返回错误Permanent deletion requires explicit confirmation——这是防误删的最后防线目标存在性校验validate_targets()仅对本地路径执行fs::try_exists检查不存在则报错中止路径解析将 Content 路径通过path.resolve_in_job(ctx)解析为 Physical 路径再重新构造SdPathBatch确保策略层拿到的是可执行的实际路径策略选择调用DeleteStrategyRouter::select_strategy与describe_strategy并记录日志策略执行strategy.execute(ctx, self.targets.paths, self.mode.clone())结果聚合统计deleted_count/failed_count/total_bytes将失败项转换为DeleteError { path, error }列表进度上报通过ctx.progress输出GenericProgress携带完成数、字节数、耗时与错误数返回DeleteOutput{ deleted_count, failed_count, total_bytes, duration, failed_deletions, mode }并实现FromDeleteOutput for JobOutput映射到统一的JobOutput::FileDelete。DeleteJob 的便捷构造器pub fn new(targets: SdPathBatch, mode: DeleteMode) - Self pub fn trash(targets: SdPathBatch) - Self // Trash 模式 pub fn permanent(targets: SdPathBatch, confirmed: bool) - Self // 需确认 pub fn secure(targets: SdPathBatch, confirmed: bool) - Self // 需确认其中permanent/secure接受confirmed布尔参数显式传入确认意图Job 元数据声明了NAME delete_files、RESUMABLE true并通过completed_deletions/started_at字段为断点续跑预留状态。模块出口统一在 core/src/ops/files/delete/mod.rs公开导出DeleteStrategyRouter、DeleteResult、DeleteStrategy、LocalDeleteStrategy、RemoteDeleteStrategy及全部 Job 类型同时包含action、input、output三个子模块FileDeleteAction/FileDeleteInput/FileDeleteOutput供上层 API 与 UI 调用。六、网络协议处理器file_delete handler 与安全校验远程删除的接收端实现在 core/src/service/network/protocol/file_delete.rs该文件已通过 protocol/mod.rs 导出为FileDeleteProtocolHandler协议名为file_delete。6.1 接收流程handle_delete_request收到远端FileDeleteMessage::Request后从CoreContext获取运行上下文实例化LocalDeleteStrategy对每个路径执行execute_deletion_with_strategy复用策略层保持远端删除 本地策略执行的一致性返回FileDeleteMessage::Response { request_id, results }。6.2 传输层流式请求/响应handle_stream实现了基于 QUIC 双向流的简单帧协议先读 4 字节大端长度前缀再读完整消息体rmp_serde::from_slice反序列化为FileDeleteMessage处理后将响应以同样的len payload格式写回发送流并 flush。6.3 安全校验路径白名单关键防线远程删除是高风险能力FileDeleteProtocolHandler内置了两层防护静态白名单set_allowed_paths可注入允许删除的路径列表测试用动态白名单get_all_allowed_paths从CoreContext中遍历所有 Library 的 Location 路径与静态列表合并最终由is_path_allowed统一裁决fn is_path_allowed(self, path: std::path::Path) - bool { // Canonicalize the target path to resolve symlinks and .. let canonical_path match path.canonicalize() { Ok(p) p, Err(_) return false }; // Check if canonicalized path starts with any allowed path for allowed in allowed_paths { if let Ok(canonical_allowed) allowed.canonicalize() { if canonical_path.starts_with(canonical_allowed) { return true; } } } false }设计要点先canonicalize再比对解析符号链接与..防止路径穿越攻击白名单为空时一律拒绝fail-safe测试test_is_path_allowed_denies_all_when_no_context明确验证无上下文配置时所有访问均被拒绝前缀匹配目标路径必须位于某个允许位置之内才算合法。单元测试覆盖了拒绝系统路径如/etc/passwd、Windows 下C:\Windows\System32\config\SAM、无上下文拒绝一切、允许位置内接受等场景为远程删除的可信执行提供了保障。七、测试验证9 个集成测试全解析策略模式的另一大收益是可测性。集成测试集中在 core/tests/delete_strategy_test.rs覆盖三个层次7.1 本地删除功能测试测试名验证点test_local_delete_strategy_permanent多个文件永久删除后不再存在test_local_delete_strategy_trash文件移入回收站后原位置消失test_local_delete_strategy_directory含子目录与文件的目录递归删除test_delete_modes_all_types三种模式Permanent / Trash / Secure逐一执行成功test_strategy_error_handling删除不存在的文件返回错误其中目录测试使用create_test_directory构造file1.txt、file2.txt、subdir/file3.txt三层结构验证递归删除的完整性。7.2 路由测试test_delete_strategy_router_local_paths本地路径选择LocalDeleteStrategy且describe_strategy返回Local deletiontest_delete_strategy_router_description再次确认本地路径描述输出稳定。7.3 云后端删除测试VolumeBackend 集成test_cloud_backend_delete_file用 OpenDAL内存模拟存储opendal::services::Memory创建CloudBackend写入文件后经backend.delete删除并验证exists为假test_cloud_backend_delete_directory构造test_dir/file1.txt、test_dir/file2.txt、test_dir/subdir/file3.txt对目录路径执行delete验证整棵目录树被清空。这两个测试证明CloudBackend.delete()对**单文件与目录remove_all 语义**均有效为LocalDeleteStrategy.delete_cloud_path提供了底层可信保障。八、技术总结为什么选择策略模式结合任务文档的 Technical Notes 与源码实现可以归纳出这一架构决策的五个理由与 FileCopyJob 架构对齐复制侧已有CopyStrategy体系LocalMoveStrategy/FastCopyStrategy/LocalStreamCopyStrategy/RemoteTransferStrategy见 copy/strategy.rs删除侧采用同构模式可降低整体认知负担与维护成本关注点分离路由决策Router与删除执行Strategy解耦新增删除后端只需实现特征无需改动 Job 主流程异构存储统一VolumeBackend抽象让本地文件系统与云端存储共享同一条execute路径未来新增存储后端如更多云厂商只影响后端层可测试性策略可独立于 Job 系统进行单元/集成测试Mock策略可轻松注入这正是 9 个测试全部独立于完整运行时环境的原因可扩展性DeleteStrategyRouter::select_strategy未来可按路径拓扑、卷类型甚至用户偏好扩展路由规则而无需改动调用方。结语与进一步阅读FSYNC-001 已经完成并全部落地DeleteStrategy特征、LocalDeleteStrategy含 Trash/Permanent/Secure 与云路径、RemoteDeleteStrategy、DeleteStrategyRouter、重构后的DeleteJob、file_delete网络协议处理器以及 9 个通过的集成测试。当前已知的演进方向源码中明确标注的 TODO是远程删除的同步确认——从发送后乐观返回升级为真正的请求/响应 超时处理。若想深入理解相关上下文建议继续阅读删除模块完整源码core/src/ops/files/delete/strategy.rs、core/src/ops/files/delete/routing.rs、core/src/ops/files/delete/job.rs、core/src/ops/files/delete/mod.rs网络协议接收端与安全校验core/src/service/network/protocol/file_delete.rs、core/src/service/network/protocol/mod.rs存储后端抽象core/src/volume/backend/mod.rs可对照的同构实现core/src/ops/files/copy/strategy.rsCopyStrategy 模式集成测试core/tests/delete_strategy_test.rs。【免费下载链接】spacedriveSpacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.项目地址: https://gitcode.com/gh_mirrors/sp/spacedrive创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Spacedrive DeleteJob 策略模式改造：本地、云端与跨设备远程删除的完整实现指南
Spacedrive DeleteJob 策略模式改造本地、云端与跨设备远程删除的完整实现指南【免费下载链接】spacedriveSpacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.项目地址: https://gitcode.com/gh_mirrors/sp/spacedrive导读本文围绕 Spacedrive 核心任务 FSYNC-001 展开完整讲解如何将DeleteJob从仅支持本地删除升级为基于**策略模式Strategy Pattern**的统一删除架构使其与FileCopyJob保持同构并具备跨设备远程删除、云端存储VolumeBackend删除两种全新能力。读完本文你将掌握 Spacedrive 文件删除模块的完整调用链——从DeleteStrategy特征定义、DeleteStrategyRouter路由选择、三种删除模式Trash / Permanent / Secure的实现细节到基于 P2P 网络的file_delete协议与路径白名单安全校验以及对应的 9 个集成测试的验证逻辑。背景与问题为什么 DeleteJob 需要策略模式在 Spacedrive 的 File Sync 体系中**Mirror镜像与Bidirectional双向**两种同步模式要求删除操作能够被派发到远端设备。改造前的DeleteJob存在三个核心短板缺少策略模式路由逻辑而FileCopyJob早已实现了CopyStrategy策略体系见 core/src/ops/files/copy/strategy.rs删除侧架构落后于复制侧不具备跨设备删除能力无法在远端设备上执行删除与其它文件操作架构不一致不利于统一维护与测试。该任务的目标状态非常明确DeleteJob使用策略模式同时具备本地Local与远程Remote两种策略最终让 File Sync 能跨设备派发删除操作。从实现完成度看该任务已全部落地任务文档status: Donestrategy.rs约 350 行、routing.rs约 50 行、网络协议处理器file_delete.rs约 250 行以及delete_strategy_test.rs中 9 个全部通过的集成测试。下文将按实现顺序逐层拆解。一、DeleteStrategy 特征删除操作的统一抽象策略模式的核心是抽象出执行删除这一行为让调用方无需关心具体删除发生在本地、云端还是远端设备。该特征定义在 core/src/ops/files/delete/strategy.rs#[async_trait] pub trait DeleteStrategy: Send Sync { /// Execute deletion of paths async fn execute( self, ctx: JobContext_, paths: [SdPath], mode: DeleteMode, ) - ResultVecDeleteResult; }要点解析Send Sync约束保证策略实例可以跨异步任务边界安全共享这是 Job 系统并发执行的基础paths: [SdPath]一次批量处理多个目标路径而非单路径逐条调用为后续按设备分组的远程删除提供接口基础DeleteMode来自job.rs的删除模式枚举决定删除语义返回值VecDeleteResult每个路径独立返回结果失败不中断整批操作。配套的DeleteResult结构体记录了单路径的完整删除结果#[derive(Debug, Clone, Serialize, Deserialize)] pub struct DeleteResult { pub path: SdPath, pub success: bool, pub bytes_freed: u64, pub error: OptionString, }其中bytes_freed用于汇总统计对应DeleteOutput.total_byteserror携带失败原因便于上层聚合为DeleteError列表。DeleteMode 的三种语义core/src/ops/files/delete/job.rs 中定义了删除模式枚举这也是整个删除模块的行为分水岭pub enum DeleteMode { /// Move to trash/recycle bin Trash, /// Permanent deletion (cannot be undone) Permanent, /// Secure deletion (overwrite data) Secure, }三者的差异直接映射到LocalDeleteStrategy的三个方法详见下一节模式语义底层操作可恢复性Trash移入系统回收站/废纸篓trashcrate 原生调用可恢复Permanent永久删除不可撤销tokio::fs::remove_file/remove_dir_all不可恢复Secure安全删除覆写数据后删除3 遍随机数据覆写 删除不可恢复且防恢复二、LocalDeleteStrategy本地与云端删除的实现LocalDeleteStrategy是策略模式下的主力选手它同时承担了本地物理路径删除与云路径删除两种职责任务文档进度中明确云路径通过 VolumeBackend 整合进本地策略无需单独的 CloudDeleteStrategy。2.1 统一入口 execute()execute()根据路径类型分派到三条路径见 strategy.rslet result match path { // Local physical path - use direct filesystem (fast path) _ if path.is_local() { let local_path path.as_local_path()...?; let size self.get_path_size(local_path).await.unwrap_or(0); let deletion_result match mode { DeleteMode::Trash self.move_to_trash(local_path).await, DeleteMode::Permanent self.permanent_delete(local_path).await, DeleteMode::Secure self.secure_delete(local_path).await, }; ... } // Cloud path - use VolumeBackend _ if path.is_cloud() self.delete_cloud_path(ctx, path, mode.clone()).await, // Remote physical or content paths not supported _ DeleteResult { success: false, error: Some(Path is remote or unsupported) }, };值得注意的是删除前会先通过get_path_size()计算路径大小文件或目录的迭代式求和用于填充bytes_freed指标。2.2 move_to_trash原生回收站支持#[cfg(any(target_os windows, target_os macos, target_os linux))] pub async fn move_to_trash(self, path: Path) - Result(), std::io::Error { let path path.to_path_buf(); tokio::task::spawn_blocking(move || { trash::delete(path).map_err(...) }).await??; Ok(()) }三个关键设计使用trashcrate 获得原生平台语义Windows 走SHFileOperation进回收站、macOS 走NSFileManager进废纸篓、Linux 遵循 XDG trash 规范spawn_blocking将阻塞式系统调用移出异步运行时避免阻塞 Tokio 工作线程通过cfg属性对非主流平台提供降级实现返回Unsupported错误——这正是任务进度中提到的macOS cfg attributes 平台适配修复。2.3 permanent_delete直接删除pub async fn permanent_delete(self, path: Path) - Result(), std::io::Error { let metadata fs::metadata(path).await?; if metadata.is_file() { fs::remove_file(path).await?; } else if metadata.is_dir() { fs::remove_dir_all(path).await?; } Ok(()) }语义清晰文件走remove_file目录递归走remove_dir_all全程使用tokio::fs异步 API 保持非阻塞。2.4 secure_delete3 遍随机覆写安全删除是三种模式中唯一的防数据恢复实现其核心是secure_overwrite_file// Overwrite with random data (3 passes) for _ in 0..3 { file.seek(std::io::SeekFrom::Start(0)).await?; let mut remaining size; while remaining 0 { let chunk_size std::cmp::min(remaining, 64 * 1024) as usize; let buffer { let mut rng rand::thread_rng(); let mut buf vec![0u8; chunk_size]; rng.fill_bytes(mut buf); buf }; file.write_all(buffer).await?; remaining - chunk_size as u64; } file.flush().await?; file.sync_all().await?; }设计要点3 遍覆写 每次sync_all落盘确保随机数据真正写入物理介质而不是停留在页缓存64 KiB 分块避免一次性分配大缓冲区适配大文件场景目录递归安全删除secure_delete_directory用显式栈迭代遍历而非递归函数先对每个文件执行覆写删除最后remove_dir_all清空目录结构覆写完成后仍调用remove_file/remove_dir_all释放目录项。2.5 delete_cloud_path云路径删除VolumeBackend 集成云路径无法用本地文件系统 API 处理因此LocalDeleteStrategy通过VolumeBackend抽象层完成删除。delete_cloud_path的完整调用链为模式限制云路径仅支持Permanent模式Trash/Secure 会返回明确错误Delete mode X not supported for cloud paths (only Permanent)获取 VolumeManager通过ctx.volume_manager()拿到卷管理器缺失则返回失败解析云路径path.as_cloud()拆出(service, identifier, cloud_path)三元组查找云卷volume_manager.find_cloud_volume(service, identifier)定位对应Volume获取后端从volume.backend取得VolumeBackend实例删除前取大小backend.metadata(cloud_path)尽力获取大小失败则记为 0不阻断删除执行删除backend.delete(Path::new(cloud_path))。而VolumeBackend特征本身定义在 core/src/volume/backend/mod.rs其中与删除直接相关的方法为/// Delete file or directory async fn delete(self, path: Path) - Result(), VolumeError;从源码结构看该特征由两个后端实现LocalBackend包装tokio::fs操作负责本地卷CloudBackend基于 OpenDALdelete()映射到 OpenDAL 的 delete/remove_all 语义负责 S3、GoogleDrive、Dropbox、OneDrive、GCS 等云服务CloudServiceType枚举即列于 backend/mod.rs。这一设计让云路径删除与本地路径删除在策略层面统一路由器无需感知底层存储差异。三、RemoteDeleteStrategy跨设备远程删除RemoteDeleteStrategy负责处理包含远端路径的删除请求其执行逻辑分两步strategy.rs3.1 按目标设备分组let mut by_device: HashMapUuid, VecSdPath HashMap::new(); for path in paths { if let Some(device_id) path.device_id() { by_device.entry(device_id).or_default().push(path.clone()); } }每个SdPath携带设备标识device_id()策略先按设备聚合路径一台设备只建立一次网络请求避免 N 条路径产生 N 次连接。3.2 逐设备发送删除请求delete_on_device的请求发送流程从ctx.networking_service()获取网络服务生成request_id Uuid::new_v4()关联请求与响应构造FileDeleteMessage::Request { paths, mode, request_id }用rmp_serdeMessagePack序列化载荷对小型消息体压缩友好通过networking.send_message(device_id, file_delete, request_data)发送记录日志后返回。需要注意的实现现状源码中delete_on_device目前返回的是乐观结果success: truebytes_freed: 0代码注释明确标注// TODO: Implement proper request/response pattern // For now, return optimistic results // In production, we need to wait for response from remote device即发送成功后暂不等待远端确认属于任务文档中Request/response pattern with timeout handling规划的待完善部分。这一点必须如实告知读者避免误解为已实现完整同步确认。3.3 网络协议FileDeleteMessage远程删除的协议载荷定义在 strategy.rs#[derive(Debug, Clone, Serialize, Deserialize)] pub enum FileDeleteMessage { Request { paths: VecSdPath, mode: DeleteMode, request_id: Uuid, }, Response { request_id: Uuid, results: VecDeleteResult, }, }Request携带待删路径、模式与请求 IDResponse以request_id回关联到对应请求并携带逐路径的DeleteResult数组。四、DeleteStrategyRouter路由决策路由器是策略模式中的决策者实现在 core/src/ops/files/delete/routing.rspub struct DeleteStrategyRouter; impl DeleteStrategyRouter { pub async fn select_strategy( paths: [SdPath], _volume_manager: OptionVolumeManager, ) - Boxdyn DeleteStrategy { let all_local paths.iter().all(|p| p.is_local()); if all_local { Box::new(LocalDeleteStrategy) } else { Box::new(RemoteDeleteStrategy) } } }路由规则极简且明确所有路径均为本地is_local()→ LocalDeleteStrategy只要存在一条非本地路径 → RemoteDeleteStrategy由远程设备各自执行本地删除因此云端路径在路由器层面并不需要特殊分支。配套的describe_strategy提供人类可读的策略描述用于日志与调试路径构成描述输出全部本地Local deletion全部远程Remote deletion (N devices)N 为去重后的设备数本地 远程混合Mixed deletion (M local, N remote)五、DeleteJob 重构从 400 行到 70 行核心逻辑任务文档进度显示重构后DeleteJob核心逻辑从约 400 行缩减到约 70 行这正是策略模式把实现细节下沉到策略类的直接收益。当前 job.rs 中run()的流程为模式标记与安全校验Permanent/Secure模式必须显式确认confirm_permanent为false时直接返回错误Permanent deletion requires explicit confirmation——这是防误删的最后防线目标存在性校验validate_targets()仅对本地路径执行fs::try_exists检查不存在则报错中止路径解析将 Content 路径通过path.resolve_in_job(ctx)解析为 Physical 路径再重新构造SdPathBatch确保策略层拿到的是可执行的实际路径策略选择调用DeleteStrategyRouter::select_strategy与describe_strategy并记录日志策略执行strategy.execute(ctx, self.targets.paths, self.mode.clone())结果聚合统计deleted_count/failed_count/total_bytes将失败项转换为DeleteError { path, error }列表进度上报通过ctx.progress输出GenericProgress携带完成数、字节数、耗时与错误数返回DeleteOutput{ deleted_count, failed_count, total_bytes, duration, failed_deletions, mode }并实现FromDeleteOutput for JobOutput映射到统一的JobOutput::FileDelete。DeleteJob 的便捷构造器pub fn new(targets: SdPathBatch, mode: DeleteMode) - Self pub fn trash(targets: SdPathBatch) - Self // Trash 模式 pub fn permanent(targets: SdPathBatch, confirmed: bool) - Self // 需确认 pub fn secure(targets: SdPathBatch, confirmed: bool) - Self // 需确认其中permanent/secure接受confirmed布尔参数显式传入确认意图Job 元数据声明了NAME delete_files、RESUMABLE true并通过completed_deletions/started_at字段为断点续跑预留状态。模块出口统一在 core/src/ops/files/delete/mod.rs公开导出DeleteStrategyRouter、DeleteResult、DeleteStrategy、LocalDeleteStrategy、RemoteDeleteStrategy及全部 Job 类型同时包含action、input、output三个子模块FileDeleteAction/FileDeleteInput/FileDeleteOutput供上层 API 与 UI 调用。六、网络协议处理器file_delete handler 与安全校验远程删除的接收端实现在 core/src/service/network/protocol/file_delete.rs该文件已通过 protocol/mod.rs 导出为FileDeleteProtocolHandler协议名为file_delete。6.1 接收流程handle_delete_request收到远端FileDeleteMessage::Request后从CoreContext获取运行上下文实例化LocalDeleteStrategy对每个路径执行execute_deletion_with_strategy复用策略层保持远端删除 本地策略执行的一致性返回FileDeleteMessage::Response { request_id, results }。6.2 传输层流式请求/响应handle_stream实现了基于 QUIC 双向流的简单帧协议先读 4 字节大端长度前缀再读完整消息体rmp_serde::from_slice反序列化为FileDeleteMessage处理后将响应以同样的len payload格式写回发送流并 flush。6.3 安全校验路径白名单关键防线远程删除是高风险能力FileDeleteProtocolHandler内置了两层防护静态白名单set_allowed_paths可注入允许删除的路径列表测试用动态白名单get_all_allowed_paths从CoreContext中遍历所有 Library 的 Location 路径与静态列表合并最终由is_path_allowed统一裁决fn is_path_allowed(self, path: std::path::Path) - bool { // Canonicalize the target path to resolve symlinks and .. let canonical_path match path.canonicalize() { Ok(p) p, Err(_) return false }; // Check if canonicalized path starts with any allowed path for allowed in allowed_paths { if let Ok(canonical_allowed) allowed.canonicalize() { if canonical_path.starts_with(canonical_allowed) { return true; } } } false }设计要点先canonicalize再比对解析符号链接与..防止路径穿越攻击白名单为空时一律拒绝fail-safe测试test_is_path_allowed_denies_all_when_no_context明确验证无上下文配置时所有访问均被拒绝前缀匹配目标路径必须位于某个允许位置之内才算合法。单元测试覆盖了拒绝系统路径如/etc/passwd、Windows 下C:\Windows\System32\config\SAM、无上下文拒绝一切、允许位置内接受等场景为远程删除的可信执行提供了保障。七、测试验证9 个集成测试全解析策略模式的另一大收益是可测性。集成测试集中在 core/tests/delete_strategy_test.rs覆盖三个层次7.1 本地删除功能测试测试名验证点test_local_delete_strategy_permanent多个文件永久删除后不再存在test_local_delete_strategy_trash文件移入回收站后原位置消失test_local_delete_strategy_directory含子目录与文件的目录递归删除test_delete_modes_all_types三种模式Permanent / Trash / Secure逐一执行成功test_strategy_error_handling删除不存在的文件返回错误其中目录测试使用create_test_directory构造file1.txt、file2.txt、subdir/file3.txt三层结构验证递归删除的完整性。7.2 路由测试test_delete_strategy_router_local_paths本地路径选择LocalDeleteStrategy且describe_strategy返回Local deletiontest_delete_strategy_router_description再次确认本地路径描述输出稳定。7.3 云后端删除测试VolumeBackend 集成test_cloud_backend_delete_file用 OpenDAL内存模拟存储opendal::services::Memory创建CloudBackend写入文件后经backend.delete删除并验证exists为假test_cloud_backend_delete_directory构造test_dir/file1.txt、test_dir/file2.txt、test_dir/subdir/file3.txt对目录路径执行delete验证整棵目录树被清空。这两个测试证明CloudBackend.delete()对**单文件与目录remove_all 语义**均有效为LocalDeleteStrategy.delete_cloud_path提供了底层可信保障。八、技术总结为什么选择策略模式结合任务文档的 Technical Notes 与源码实现可以归纳出这一架构决策的五个理由与 FileCopyJob 架构对齐复制侧已有CopyStrategy体系LocalMoveStrategy/FastCopyStrategy/LocalStreamCopyStrategy/RemoteTransferStrategy见 copy/strategy.rs删除侧采用同构模式可降低整体认知负担与维护成本关注点分离路由决策Router与删除执行Strategy解耦新增删除后端只需实现特征无需改动 Job 主流程异构存储统一VolumeBackend抽象让本地文件系统与云端存储共享同一条execute路径未来新增存储后端如更多云厂商只影响后端层可测试性策略可独立于 Job 系统进行单元/集成测试Mock策略可轻松注入这正是 9 个测试全部独立于完整运行时环境的原因可扩展性DeleteStrategyRouter::select_strategy未来可按路径拓扑、卷类型甚至用户偏好扩展路由规则而无需改动调用方。结语与进一步阅读FSYNC-001 已经完成并全部落地DeleteStrategy特征、LocalDeleteStrategy含 Trash/Permanent/Secure 与云路径、RemoteDeleteStrategy、DeleteStrategyRouter、重构后的DeleteJob、file_delete网络协议处理器以及 9 个通过的集成测试。当前已知的演进方向源码中明确标注的 TODO是远程删除的同步确认——从发送后乐观返回升级为真正的请求/响应 超时处理。若想深入理解相关上下文建议继续阅读删除模块完整源码core/src/ops/files/delete/strategy.rs、core/src/ops/files/delete/routing.rs、core/src/ops/files/delete/job.rs、core/src/ops/files/delete/mod.rs网络协议接收端与安全校验core/src/service/network/protocol/file_delete.rs、core/src/service/network/protocol/mod.rs存储后端抽象core/src/volume/backend/mod.rs可对照的同构实现core/src/ops/files/copy/strategy.rsCopyStrategy 模式集成测试core/tests/delete_strategy_test.rs。【免费下载链接】spacedriveSpacedrive is an open source cross-platform file explorer, powered by a virtual distributed filesystem written in Rust.项目地址: https://gitcode.com/gh_mirrors/sp/spacedrive创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考