如下图，打开app文件夹一直打不开。
服务器是centos7，服务端是5.1.3。重启服务端和重启服务器都无效。
服务器端日志有相关的错误吗？seahub.log seahub_django_request.log
log里没有错误信息
网页端打开后是怎么样的？截图过来看下
网页端也是一样的，图现在没了。确认文件夹里没有重要东西之后已经删掉了。重新创建之后正常。
能否提供下重现步骤？看样子这些重名子目录应该是客户端创建的
具体重现步骤不确定，不过本次的问题是发生在移动文件夹的时候出现的，就客户端内使用剪切粘贴
试试在服务器端把资料库还原下
最新的6.0.4版本再次重现该问题。问题确定是在win客户端内使用剪切粘贴后出现的
你好，我觉得原因可能是这样的：
在文件浏览器中 点击文件夹会触发这个函数
void FileBrowserDialog::onDirClicked(const SeafDirent& dir) { const QString& path = ::pathJoin(current_path_, dir.name); backward_history_.push(current_path_); forward_history_.clear(); enterPath(path); }
在enterPath 中就已经开始对navigator 增加按钮了（如果这时候客户端断网了，或者网络较差，就能出现题主这样的问题，就像进入一个重名的子目录，实际并不存在）。
解决的方法也很简单，把这部分对对navigator 增加按钮的操作放到网络请求成功后的回调函数（void FileBrowserDialog::onGetDirentsSuccess(bool current_readonly, const QList& dirents)）中即可。
因为是在局域网内操作，网络问题导致的可能性不大。
非常有可能是某种情况下使用剪切粘贴之后，目录所对应的索引更新错误了。我正在尝试稳定重现的步骤。有情况我会继续更新。
多谢，我们这边也会查下
一直未能找到重现方法。不过再次回去看之前有问题的文件夹发现已经好了。
服务端是不是有类似的检查机制或者在非常大的资料库中使用移动文件或者文件夹，是有操作队列这种不立即生效的机制？
考虑重现环境为非常大的资料库，出现问题的库为公共库，56gb，有非常大的文件也有非常多的碎小文件。
当时的操作情况：
在此之前，这个修改详情显示的是未知错误。
今天再次出现该问题，重现步骤很清晰，删除一个文件之后，对其进行恢复操作，操作之后提示成功但是在原文件夹中并未发现恢复文件，且在恢复列表仍有该文件。
再次进行恢复操作之后，文件夹出现该现象，直到现在也无法打开。
在历史中查看也可以看到这个问题
并且这次直到现在已经一天过去了都没有恢复正常。
可以提供环境来查明问题