无法理解的bug，这又是什么文管的设计巧思？

你是不是按修改时间排序了

首先文管不是单纯按字符从前往后排，也要看类型，但细节我也没太搞懂。

这个看着是0827和0830的各类型格式是一致的，所以归到同一类了，然后0829的类别不一样了。

比如说，0829的，如果中间改成718.00T，这种格式一致了之后，那就是按咱们所要的顺序来排了。

所以感觉是先按格式类型归类，归类后，各类内部再做详细排序了。

来自deepin的“甜菜”算法吗？有点意思。

这是什么硅基生物排序法……给碳基人类使用的文管排序不应该是，选择按“名称”排序后，无论格式如何都按照A-Z或者数字排序吗？最多有个文件夹和文件分开排列。

大方向上是分字符类型（字母、数字、汉字、其他），但再往详细里说，我还真搞不那么详细了。

我印象中win是按位排序，跟linux命令行中的排序应该一样。

其他linux发行版的文管好像也不是按位排。

比如1、10、2：win和linux命令行中是1、10、2，linux文管里面是1、2、10。

深有体会

ubuntu和debian的排序逻辑还是挺科学的，deepin因为稳定性问题没有作为主力重度使用过，我还是第一次发现deepin的文件居然这样排序。

emm研究了一下貌似是bug，刚提交项目组去解决了，感谢抓虫

• 感谢反馈,测试环境复现了一下该问题,
• 应该是文件名称中存在多个小数点时,该场景需要优化下,已反馈给研发稍后处理 ~