命令行拷贝速度和smb之间拉的速度一样

@深度之家

@neko

你的反馈我已经同步给文管负责人。

文件删除效仿windows给个选项是直接删除还是放回收站就好。

速度慢跟这个可能没啥关系

第三点

第一点可能要从底层开始看吧，哪怕是微软windows11那个文件管理器也被发现比win10还慢，win10刚发布那会儿比win7慢，也都这么熬过来咯😂 。

我反倒觉得和业务层面有关系，我粗略看过文管的代码，以下是造成原因猜测，如果单独用命令行命令，cp自然都可以达到该有的速度，但是到了上层，不仅要完成复制操作，还希望实时观察数据的流向和动作，包括显示百分比，包括文件管理器的刷新等等操作，是这些一系列的附加操作(当然肯定是某个附加操作在特定情况很卡[代码写的有问题])导致的，我感觉kde和gnome的文管都是尽量避免这些操作，一般都是手动刷新，及时不同步文件，界面上显示迟缓都会优先保证流畅度，windows也是，但是deepin的响应是最及时的，感觉就像是一直都在监控文件那样，额外占用很多资源，对于底层的挂载层，可能有些有问题，但是传输速度一般都是稳定的，也决定了你不论使用什么去复制速度都应该这个级别

底层有问题，也会影响上层，这也是一种，就像我以前遇到过，libmtp这个库，凡是基于这个库做的挂载，挂载出mtp，代码里面用qt每进行一个文件的QFileInfo类似的读取文件信息的操作，就需要几ms-几百ms，而换做非libmtp封装的挂载层，好像例如go-mtp还是啥，我忘了，几乎每次QFileInfo都差不多忽略不计时间，很快，，但是gnome和deepin的挂载都是使用的gnome的gvfs-mtp挂载，这个家伙就是使用到了libmtp，但是gnome的文管对于文件信息的读取明显比deepin的文管少太多次了，所以，很明显感觉gnome的mtp挂载就是更流畅，其实底层也是有问题的，但是文件的传输速度其实都差不多，ui的流畅度就相差明显。底层越有问题，上层设计缺陷或者为了功能牺牲速度的方案暴露速度慢和卡顿的情况就越明显。这种设计对机械硬盘的速度来说就是很痛苦的，走到哪都要卡，反观使用固态，读取速度上来了，就掩盖了很多上层问题

第一个问题已优化。第三个问题需要开启组策略中的配置就可以了。

反正deepin自带的文件管理器非常难用，我基本上都用DoubleCmd代替了。

这个速度有问题不，三块盘都是SSD的。两个NTFS模式的盘在复制，一个插在主板上512G，一个插在前面的USB口上128G。还一个装的DEEPIN系统512G

太慢了，两个外接硬盘互传150G数据，4Mb/s的确震惊到我了😂

说的不错，我是外接固态拷贝进外界机械硬盘，命令行操作速度没有问题

如果是拷贝大文件，插的是3.0口，那速度不对

请问策略组如何开启，感谢

3已经支持，此功能后续可能会考虑开放出来。1 、2问题研发定位中确定原因后会进行修.

dde-dconfig --set -a org.deepin.dde.file-manager -r org.deepin.dde.file-manager -k dfm.trash.allfiletotrash -v true

灰常感谢！