Remotely-Save插件空文件夹同步问题的技术解析与解决方案

背景与问题现象

在Obsidian笔记管理工具中，Remotely-Save插件作为连接本地仓库与云端存储的桥梁，其同步机制对用户数据安全至关重要。近期用户反馈在Windows系统下使用腾讯云COS作为存储后端时，空文件夹同步存在异常行为：首次同步可保留空文件夹，但二次同步后空文件夹会被自动删除。该现象在插件版本0.5.24与Obsidian 1.6.7环境下稳定复现。

技术原理分析

S3协议存储特性

云端对象存储服务（如腾讯云COS）基于S3协议实现，其核心设计采用扁平化存储结构。与传统文件系统不同，S3协议中：

1. 无原生目录概念：所有对象以Key-Value形式存储，路径分隔符"/"仅为Key的命名约定
2. 伪文件夹实现：控制台展示的"文件夹"实际是包含特定前缀（如folder/）的零字节对象
3. 同步逻辑差异：当本地存在真实空文件夹时，插件无法在云端创建对应标记对象

插件同步机制

Remotely-Save采用双向同步策略时：

1. 首次同步会建立基础目录结构
2. 二次同步进行差异比对时，由于云端缺乏空文件夹标记对象，触发删除逻辑
3. 同步过程中未自动创建占位文件，导致目录状态无法持久化

解决方案

推荐方案：占位文件法

1. 在需保留的空文件夹内创建隐藏文件（如.keep）
2. 文件内容可包含说明文本（示例）：

   # This file maintains folder structure
   # DO NOT DELETE
   

3. 优势：符合版本控制惯例，兼容所有S3兼容存储

替代方案：手动标记（适用于运维场景）

1. 通过COS控制台创建同名"文件夹"（实际生成零字节对象）
2. 执行同步操作拉取目录结构
3. 注意：此方法在批量操作时效率较低

深度优化建议

对于技术用户可考虑以下进阶方案：

1. 插件配置增强：

   // 伪代码示例：同步时自动生成占位文件
   if (folder.isEmpty() && config.keepEmptyFolders) {
       folder.create('.placeholder');
   }
   

2. 同步策略优化：添加"preserveEmptyDirs"配置项控制删除行为
3. 目录标记标准化：采用.rsync_metadata等隐藏文件存储同步状态

总结

对象存储服务的架构特性导致空文件夹同步存在固有挑战。通过理解S3协议的设计哲学和Remotely-Save的同步逻辑，用户可采用创建占位文件这一简单有效的方法保证目录结构持久化。对于插件开发者，未来可考虑引入更智能的目录状态管理机制来提升用户体验。