Immich-go项目中的文件上传问题分析与解决方案

问题背景

在Immich-go项目中，用户报告了一个关于文件上传功能的异常行为。当用户尝试通过immich-go工具导入Google Takeout压缩包中的照片时，系统未能正确上传那些已在服务器上被标记为删除的文件。

问题现象

用户的操作流程如下：

1. 将Google Takeout压缩包解压到/externalLibrary2目录
2. 设置该目录为外部库路径
3. 等待Immich完成处理
4. 从外部库路径中移除该目录
5. 执行库扫描和刷新操作
6. 使用immich-go导入原始压缩包

此时系统并未上传任何文件，日志显示所有文件都因"服务器上已存在同名、同日期和同大小的资产"而被跳过上传。然而数据库查询显示这些文件实际上已被标记为删除(deletedAt字段有值)。

技术分析

深入分析这个问题，我们可以发现几个关键点：

1. 元数据残留问题：Immich系统在外部库被移除后，虽然标记了文件为删除状态，但仍保留了这些文件的元数据记录(isOffline标记为true)。

2. 上传逻辑缺陷：immich-go的上传检查机制仅比对文件名、日期和大小等基础信息，未能正确处理已被标记删除但仍存在于数据库中的记录。

3. 数据一致性挑战：这反映了分布式系统中常见的数据一致性问题——当文件从存储中移除后，相关的元数据清理可能不完全。

临时解决方案

对于急需解决问题的用户，可以通过直接操作数据库来清理残留的离线资产记录。需要执行以下SQL语句：

-- 清理相关关联表数据
DELETE FROM albums_assets_assets WHERE "assetsId" IN (SELECT id FROM assets WHERE "isOffline"='t');
DELETE FROM asset_faces WHERE "assetId" IN (SELECT id FROM assets WHERE "isOffline"='t');
DELETE FROM asset_files WHERE "assetId" IN (SELECT id FROM assets WHERE "isOffline"='t');
DELETE FROM asset_stack WHERE "primaryAssetId" IN (SELECT id FROM assets WHERE "isOffline"='t');
DELETE FROM memories_assets_assets WHERE "assetsId" IN (SELECT id FROM assets WHERE "isOffline"='t');
DELETE FROM shared_link__asset WHERE "assetsId" IN (SELECT id FROM assets WHERE "isOffline"='t');
DELETE FROM tag_asset WHERE "assetsId" IN (SELECT id FROM assets WHERE "isOffline"='t');

-- 清理主表数据
DELETE FROM assets WHERE "isOffline"='t';

重要警告：直接操作数据库存在风险，仅建议熟悉数据库操作的技术人员在充分备份后执行。

长期改进方向

从系统设计角度，这个问题指出了几个需要改进的方向：

1. 上传逻辑增强：immich-go应检查资产的删除状态而不仅仅是存在性。

2. 外部库管理：Immich应提供更完善的工具来清理已移除外部库的残留数据。

3. 数据生命周期管理：系统需要更明确的离线资产处理策略和自动化清理机制。

总结

这个问题揭示了分布式媒体管理系统中的数据一致性和生命周期管理挑战。对于普通用户，建议等待官方修复；对于技术人员，在充分理解风险的前提下可以使用提供的SQL方案临时解决问题。长期来看，系统需要更完善的元数据管理机制来避免类似问题。