【严重数据损坏 Bug】飞牛双向同步会把写入中的文件误判为完成文件并同步 0KB 版本覆盖真文件
【问题概述】
在 macOS 上使用飞牛同步（双向同步模式）时，我连续遇到文件内容被 0KB 文件覆盖导致数据丢失的问题。
这个问题与网络环境无关——真正的触发点是：
飞牛同步无法判断“文件正在写入中”，会在文件处于 0KB/未写完阶段就提前触发同步。
导致云端、本地均被错误的 0KB 临时文件覆盖。
这个问题在从相机/SD卡/外置硬盘拷贝大文件到同步目录时必然触发，属于高危级别的文件损坏问题。
【问题复现逻辑（100%可重现）】
场景：
我把相机里的大文件（照片/视频）拷贝到 Mac 的一个文件夹，而这个文件夹正好是飞牛的同步目录。
macOS 写入文件时有一个自然过程：
- 先创建文件名
- 文件大小是 0KB
- 随着拷贝进行，文件大小逐渐增长
- 最后写入完成
飞牛同步的机制是“每隔数秒扫描一次同步目录”，问题就出在这一步。
复现过程：
1. 文件刚被复制到同步目录
拷贝开始时，目标文件在本地呈现为：
- 名字已经生成
- 文件大小 = 0KB
- 内容尚未写入完成
2. 飞牛同步扫描到新文件（0KB）
飞牛的实时扫描机制会直接认为：
“这是一个新文件，需要立即同步到云端”
于是把****这个 0KB 的未完成文件上传到了云端。
3. 拷贝继续进行，本地文件逐渐变大
但此时云端已经存了一份错误的 0KB 文件版本。
4. 下一轮同步扫描发生 —— 云端反向覆盖
飞牛在下一次同步检测时会看到：
- 云端：文件存在（大小 0KB，时间戳新）
- 本地：文件正在写入，大小在变化
飞牛同步机制基于时间戳判断，而不是写入状态，因此会认为：
“云端版本更新 → 应该覆盖本地”
于是本地正在写入的大文件被云端的 0KB 版本覆盖。
最终结果：
真实文件彻底被 0KB 文件取代，本地和云端都损坏。
全过程与网络无关，是****文件写入机制 + 飞牛同步机制冲突造成的。
【问题核心原因】
飞牛同步缺少两个最基本的同步客户端能力：
1. 无法判断文件正在写入中（缺乏文件句柄检测）
正常同步软件（如 Nextcloud、Syncthing、Resilio）会判断：
- 文件是否仍在被系统写入
- 文件句柄是否被占用
- 文件大小是否在变化
- 文件是否已关闭
只会在“文件写入完成”后才开始同步。
飞牛同步显然没有做到这一点。
2. 同步判断完全依赖时间戳，不校验文件完整性
飞牛看到云端的 0KB 文件时间更近，就直接覆盖本地，不检查：
- 文件是否为临时文件
- 是否处于复制阶段
- 文件大小是否突然变成异常值
- 是否需要分块校验
这样的策略必然导致数据丢失。
【影响范围】
这个 bug 会影响：
- 所有双向同步的用户
- 所有 macOS 用户（macOS 写入方式特性导致更易触发）
- 所有从 SD 卡/相机/外置设备拷贝大文件到同步目录的场景
- 所有使用同步目录作为“素材导入路径”的用户
- 视频、照片、文稿等容易写入较慢的大文件
这是确定性触发的文件损坏问题，不是偶发性错误。
【问题严重性】
该问题属于高危级的数据破坏类 Bug：
- 数据损坏不可逆
- 同步机制错误反复覆盖
- 云端、本地都会丢失
- 无任何错误提示
- 用户根本不可能恢复
在使用飞牛双向同步时，这是一个“踩一次就丢数据”的灾难性缺陷。
【建议解决方案（供官方参考）】
其他成熟同步软件标准做法包括：
- 同步时必须检测文件是否仍在写入（文件锁/文件句柄）
- 对写入中的文件禁止触发同步任务
- 同步前校验文件大小是否稳定
- 使用临时文件机制（如 .part / .tmp）完成后再 rename 正式文件
- 同步客户端应该等待文件写入完成后 1～2 秒再同步
- 杜绝把 0KB 文件当成“完成文件”推送到云端
这些都属于同步软件的基础功能。
【临时解决方案】
在官方修复之前，建议官方公开说明：
不要把飞牛同步目录当作素材导入目录使用。
特别是不要在里面直接写入大文件。
然后，目前的解决方法是，拷贝的时候暂停同步，拷贝完成以后再启用同步功能，可以解决这个问题。
2025-11-24 22:14:16
2025-11-26 19:25:27