RomM平台删除机制的技术解析与文件系统残留问题

问题背景

在RomM 3.8.3版本中，用户报告了一个看似平台删除不彻底的问题：通过UI界面删除游戏平台后，扫描功能仍会尝试扫描已删除的平台。经过深入分析，这实际上是一个设计行为与用户预期之间的理解差异问题。

技术原理

RomM的删除机制采用了"软保留"设计策略：

1. 数据库层面：平台记录确实会被完全删除
2. 文件系统层面：平台对应的游戏目录会被有意保留
   • 保留内容包括：
     • 平台文件夹本身
     • 该平台下的所有游戏文件
   • 这种设计是为了防止用户误操作导致数据丢失

问题重现场景

当用户执行以下操作流程时会出现所述现象：

1. 通过UI删除多个平台（如不同年代的DOS平台）
2. 不手动清理文件系统中的空目录
3. 执行"新平台扫描"操作
4. 系统会重新检测到这些空目录并尝试扫描

解决方案

对于希望完全清理的用户，需要执行双重清理：

1. 数据库清理（通常由系统自动完成）
2. 文件系统清理：
   • 手动删除/library/roms下的对应平台目录
   • 对于Docker用户，需注意卷挂载点的清理

最佳实践建议

1. 删除前的准备：

   • 备份重要游戏数据
   • 记录平台配置信息

2. 删除后的检查：

   • 验证文件系统残留
   • 检查挂载点一致性（特别是Docker环境）

3. 批量操作建议：

   • 对于大量平台的清理，建议编写脚本自动化处理
   • 可结合数据库查询确认删除状态

设计思考

这种保留设计体现了RomM的"数据安全优先"理念，虽然可能造成一些使用困惑，但有效防止了以下风险：

• 误删除导致的数据丢失
• 批量操作失误
• 系统崩溃时的数据恢复

对于高级用户，可以考虑通过hook或插件机制实现更灵活的清理策略，但这需要权衡系统复杂性和用户体验。

总结

RomM的平台删除机制是一个经过深思熟虑的设计选择，理解其背后的技术原理和安全考量，可以帮助用户更有效地管理系统资源。在实际操作中，用户应当养成同时关注数据库状态和文件系统状态的习惯，特别是在使用容器化部署时更要注意挂载点的管理。