本帖最后由 naihe2010 于 2014-7-1 12:43 编辑
首先，非常感谢Ubuntu Kylin团队的工作，让我等Linux用户可以使用快盘这款产品。
毫无疑问，金山快盘是目前来说唯一在Linux工作比较好的同步软件（Dropbox等国外产品不算，因为总是被墙）
通过几天的试用，我发现快盘目前也是存在一些问题的，虽然都是小问题，但毕竟是问题。在这里一并提出来，希望团队早日修复。
我的系统是ArchLinux最新版，采用AUR上的kuaipan4uk打包安装。我查过了，目前是打包的最新的deb二进制包，即2.0.0.2版本。
问题如下：
- 不支持大文件。
金山的快盘免费用户的容量已达到2T，而kuaipan4uk还不支持大于2G的文件，这不得不说很可惜。
同时也有个问题就是，假如kuaipan4uk不能上传大于2G的文件，但是有用户提示，也还是能接受的。即，用户可以自己分块儿等来避免，但是现在的kuaipan4uk是默默地忽略了，让用户毫不知道。 - 过滤机制有问题。
我发现，kuaipan4uk的文件更改机制是采用了inotify的监视。但是，对于忽略的文件，kuaipan4uk也同时不再监视了。
于是，造成的结果就是，很多用户想要忽略的一些临时文件，最终不再“临时”了的时候，都会变成用户需要同步的正常文件的。可是，由于kuaipan4uk没有监视它们，导致程序不能发现它们的更改。
所以，我觉得，快盘应该采用inotify监视所有的文件，而只有真正上传/下载的时候，才忽略掉那些用户选择了忽略的文件。 - 过滤条目没有保存。
很多Linux用户，是会大量使用dot文件的。但是快盘默认忽略.开头的文件。
作为程序开发者，这也没有问题。但是，当用户自己选择不要忽略dot文件以后，每次程序重新启动，就又自动忽略了。
即，用户的过滤选择，没有保存下来。 - 云端更新不能同步。
这里的同步，指的是自动同步。即，服务端已经有很多变动了，但是客户端即kuaipan4uk这里，却始终静悄悄地没有反应。一定要用户手动“立即同步”，才能同步过来。
不知道这个bug是不是跟网络情况有关，但我试过了，不是同步时间的问题，我测试了几个晚上，都是服务端更新10个多小时后，客户端仍然没有同步过来。 - 重命名算法比较可怕。
这个可能算是快盘云端算法实现的问题吧。即，一旦用户目录里有了重命名的目录，而目录下面又文件比较多的情况下，kuaipan4uk将进入大量的“scaning"状态，远远比删除掉源文件再下载新文件要时间长很多很多倍。
可能快盘云端是针对文件设计的，于是，客户端一个目录的改变，服务端要进行大量的文件名修改操作。但是，为什么会scaning那么长的时间呢？
以上，就是我目前为止测试出现的bug。
另外还有一个问题，就是kuaipan4uk有没有开源的计划。因为如果有了大量程序员的加入，很多使用上的小问题的修复，可能就会快得多。而Ubuntu Kylin团队，则可以专注于解决更核心的问题。
再次，对团队的工作表示感谢。
|
ibXLiveImpl.cpp(370)