本帖最后由 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团队,则可以专注于解决更核心的问题。
再次,对团队的工作表示感谢。