Remotely-Save插件同步冲突问题的技术分析与解决方案

问题现象

在多设备同步场景中，用户报告了一个典型问题：当在Windows端创建Obsidian库并同步到OneDrive后，在Android设备新建库并执行首次同步时，插件正常完成了文件下载。但随后再次手动同步时，插件却意外触发了上传操作，进而导致Windows端也跟随上传，形成循环覆盖。值得注意的是，整个过程中用户并未对文件进行任何修改。

技术背景

Remotely-Save作为Obsidian的云同步插件，其核心功能是通过比对本地与云端文件的修改时间戳来决定同步方向。理想状态下，当两端文件未发生变化时，系统应保持静默状态。该问题暴露出时间戳比对机制存在逻辑缺陷。

根本原因分析

1. 时间戳比对异常：初步判断是插件在解析文件元数据时，对时区处理或时间格式转换存在偏差，导致系统误判文件需要更新。
2. 同步触发机制：Android端完成下载后，某些系统级操作（如文件索引更新）可能意外修改了文件属性，触发插件重新评估同步状态。
3. 双向同步设计：当前版本采用较为激进的冲突解决策略，当检测到不一致时倾向于用本地版本覆盖远程。

解决方案

1. 版本升级：开发团队已在0.4.x版本中重构时间比对逻辑：

   • 引入更精确的UTC时间对比算法
   • 增加文件哈希校验作为二次验证
   • 优化时区转换处理流程

2. 临时应对措施：

   • 在Android端首次同步后，可手动清除插件缓存
   • 暂时关闭自动同步功能，采用手动触发模式
   • 对关键文件进行版本备份

最佳实践建议

1. 多设备同步规范：

   • 建议所有设备先安装相同插件版本再进行初始化
   • 首次同步时保持网络稳定，避免中断
   • 大文件库建议分批次同步

2. 监控与调试：

   • 启用插件的详细日志模式
   • 定期检查.sync.json等元数据文件
   • 关注文件修改时间的系统级变化

技术展望

该问题的修复体现了分布式同步系统的典型挑战。未来版本可能引入：

• 基于内容识别的智能同步策略
• 客户端同步队列管理机制
• 更细粒度的冲突解决配置选项

用户可通过测试新版本来验证修复效果，建议通过BRAT渠道获取最新测试版进行验证。对于生产环境中的重要数据，仍建议保持定期备份的习惯。