关于修改文件夹名称
最近修改了几次文件夹的名称
之后在同步日志里发现每次修改名称的同步操作是先把本地改过名字的文件夹作为新的文件夹+文件上传到服务器，然后把服务器上旧名称的文件夹给删除
如果路径里有配图文件夹”_image”则所有的图片也都会重新上传
感觉这样一来效率低而来浪费流量啊-_-|
进行改操作的站点是：https://gms.bitcron.com/
最近修改了几次文件夹的名称
之后在同步日志里发现每次修改名称的同步操作是先把本地改过名字的文件夹作为新的文件夹+文件上传到服务器，然后把服务器上旧名称的文件夹给删除
如果路径里有配图文件夹”_image”则所有的图片也都会重新上传
感觉这样一来效率低而来浪费流量啊-_-|
进行改操作的站点是：https://gms.bitcron.com/
@张顺 抱歉，是这个机制。 不是效率的问题，而是一次行为本身涉及到了其所有子对象的数据变化，这样处理，可以保证数据原子化，从而可以应对分布的逻辑。
@Hepo 如果是通过dropbox同步所以无从知晓具体的修改内容这么做感觉也能理解，但是用ME直接编辑如果能有更好的处理方式就更好了，发现以后不太敢随便改文件夹名字和目录结构了，只好在本地别处先打草稿准备等确定以后再传bitcron了😂
@顺子 其实修改的频率本来就不高，产生的流量也基本上可以忽略。
个人建议，其实没必要因为这个技术细节而约束自己的使用习惯……
下面是一些技术性的解释，其实不看也没有关系：
服务端的结构是如此， 也决定了 ME 的表现，每次同步前先确定哪些文件被删除了、哪些是新增的，而不会有 rename 的概念。不仅如此，ME 除了接入 Bitcron 之外，其它的云端比如七牛、AWS S3 也是支持这种逻辑的， Folder 以及 其所有子文件，本质上只是基于路径的约定，而不存在实质关系类型的归属。
实质上， Dropbox 的客户端、服务端也是这种技术逻辑，只是它有增量同步以及服务端本来存储了所有文件的 hash 比对，可以实现旧文件的 “秒传”，毕竟 Bitcron & ME 不是专门的同步系统，要进一步这样处理，不可能的，系统冗余，顾此失彼，重心丢失。
:)
@Hepo 嗯，主要是这个wiki刚开始弄还没想好最终形态，所以前期可能会改来改去的，要是确认了就不存在这种问题了。突然发现这个评论没邮件通知的？