remote_client_sync模式当同步路径中包含#，数据不同步 about gofs

[lemon65535]

非常感谢，我刚已经拉取主分支重新测试了，问题已修复！

[mstmdev]

新增-copy_link和-copy_unsafe_link命令行参数支持在磁盘间进行同步时，控制是否同步软链接指向的真实文件。
为了保持代码的稳定性，目前这两个命令行参数只会在本地磁盘间同步时生效。

#231 已合并 @lemon65535

[mstmdev]

感谢反馈，文件路径中包含特殊字符会导致路径被截断，已修复，请拉取主分支最新代码重新编译试下 @lemon65535

Fixed by #221

[lemon65535]

我这边测试还发现一个问题，当原目录下存在软链时:

1. 当软链指向的是一个不存在的地址时，目标不同步软链文件；
2. 当软链指向的是一个存在的文件时，目标目录下会将该软链指向的文件重新复制一遍；

这个有考虑修复一下吗？

[mstmdev]

两种情况下，你期望的行为分别是什么呢？

[lemon65535]

1. 当软链指向的是一个不存在的地址时，创建一个软链文件，指向该不存在的文件地址
2. 当软链指向的是一个存在的文件时，目标目录下也对应创建一个软链文件，指向一个存在的文件(这样不需要再复制一遍源文件)

这样能够保证原始目录和目标目录的一致性，我这边用rsync做同步时也是这样的一个效果。

[mstmdev]

需要做一些测试来评估下，因为涉及到跨操作系统和存储目标非磁盘的情况，还有会对实时同步的逻辑造成影响。

第2种情况下重复复制确实是一个问题，需要一个解决方案来优化这个问题（覆盖全场景或者部分场景）。

[lemon65535]

我理解rpc可以通知出当前目录该软链的变更，至于是否进行处理，应该由client端自行决定。针对我说的这个场景，主要实现逻辑在sync/remote_client_sync.go这个文件中，是否可以考虑在remote_client_sync.go实现的时候进行优化？

[mstmdev]

嗯，针对这个具体的场景，你的思路是对的，细节上可能还会牵扯出更多的相关逻辑需要修改。

比如如果要支持软链接的下发与创建，就得考虑是否支持软链接的上传等等。同时也需要考虑是否会因为软链接导致source和dest目录之外的文件被恶意访问的问题，一些开放接口上就需要支持安全边界的检查和控制。

还有linux上的软链接同步到windows该如何处理。两者的软链接看起来好像并不兼容，而且windows上创建软链接貌似还需要管理员的权限，让软件的使用变得更加复杂。

另外除了这个场景之外，想要保持基本规则的统一，需要考虑与MinIO，SFTP等集成时如何处理软链接的问题。

[mstmdev]

可以先实验性的实现部分功能看看效果，以及评估对于现有代码会不会产生大的破坏。
目前来看，对于软链接，除了MinIO，其他场景理论上应该都是可以实现的。
对于MinIO，或许可以参考git对于软链接的实现，将其存储为一个特殊的文件来处理。

Features	Create	Remove	Read
Local Disk	✅	✅	✅
Remote Disk Server	✅	✅	✅
Remote Disk Client	✅	✅	✅
Remote Push Server	✅	✅	✅
Remote Push Client	✅	✅	✅
SFTP Pull Client	✅	✅	✅
SFTP Push Client	✅	✅	✅
MinIO Pull Client	❌	❌	❌
MinIO Push Client	❌	❌	❌
File Server	✅	✅	✅

[mstmdev]

另外对于软链接无法低成本的实现文件的实时同步，只能通过手动全量同步或者定时同步来实现同步软链接指向的真实内容，即软链接不支持实时同步。

对于软链接指向的文件在source目录之内和source目录之外，具体处理逻辑可能也会不同，出于安全因素，需要考虑是否允许同步链接到source目录之外的真实文件（在全量同步或定时同步的场景下）。

[lemon65535]

软连接不支持实时同步是因为什么原因呢？fsnotify能够识别出软连接文件的变更吗？
如果软连接指向的文件指向source之外，是否能通过参数让用户决定如何处理？

[mstmdev]

我试了下好像不能，我也查了下资料，软链接应该是只能触发Create与Remove这样的事件，应该是软链接的自身特性导致的，不是库的原因。

另外如果软链接指向了source目录下文件，并且假设软链接的文件内容变更也会触发相应事件，那此时可能会有两个协程同时对同一个文件进行更新（源文件和软链接触发了2个事件），也是存在一定矛盾的，软链接不支持实时同步反而可以规避这个问题。

第二个问题提供参数让用户参数控制也是可以的，但是会增加复杂度，需要验证和评估下。

[lemon65535]

针对第一点，照这个理解，确实不太适合做成实时同步。
定时同步以及手动全量同步能支持也可以理解，那照这样来看的话，干脆实时同步针对软链就不处理，软链的问题放在定时同步或全量同步中进行处理，能够更简单的实现功能。

[mstmdev]

赞同，以下是我的理解，是否和你的想法一致？

在实时同步场景下,软链接只处理Create与Remove事件，如果dest支持软链接则创建软链接，如果不支持软链接（如MinIO），则创建一个自定义的特殊文件来记录软链接信息，例如这个例子。

另外可以通过新增一个flag来支持同步软链接指向的真实文件，而不是链接本身，类似与rsync的-L参数，因为软链接可能指向source目录外的文件，存在需要同步原始文件的需求。

考虑到安全问题，还需要新增一个flag来控制指向source目录之外的软链接的行为。

[lemon65535]

是的，如果能支持到这个功能就很棒了，非常感谢哈！

[mstmdev]

实现同步软链接本身作为默认行为，已合并 #230

[mstmdev]

实现同步软链接指向的真实文件，存在跨平台的兼容性，递归嵌套等问题，以及组合不同的使用方式很容易产生BUG，测试难度较大，目前开启一个实验性的PR #231

[lemon65535]

不好意思，最近几天比较忙。上上周我使用sersync2+rsync方式尝试同步目录的时候，就碰到了软链循环引用导致死循环的问题，这个确实需要考虑的。另外新feature是已经合并至master分支了吗？需要我本地拉下来build是吧。

[mstmdev]

目前主分支默认会同步软链接符号本身，并不会同步符号指向的内容。因为对于同步真实指向的文件还有一系列的问题没有解决，如你遇到的死循环问题等等。
目前在 #231 进行实验性的尝试，暂时不会合并