无法删除Linux目录 – 无限递归

前端之家收集整理的这篇文章主要介绍了无法删除Linux目录 – 无限递归前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们在支持我们的版本控制服务器的RHEL6 VM上有一个NFS挂载 – 最近,其中一个存储库有点疯狂,这就是我在服务器上找到的:
ls -latri repo.git/refs/heads/

total 28
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 .
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551209 drwxr-xr-x. 3 git git 4096 Jun  1 22:09 ..

当我对着dir运行树时,它似乎是无限递归的 – 例如:

repo.git/refs/heads/
├──
│ ├──
│ │ ├──
│ │ │ ├──
│ │ │ │ ├──
│ │ │ │ │ ├──
│ │ │ │ │ │ ├──
│ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──

我试图通过其inode ref删除存储库:

[root@node repo.git/refs]# ls -latri
total 16
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 heads

[root@node repo.git/refs]# find . -inum 5551210 -exec rm -rf {} \;
rm: cannot remove `./refs/heads': Directory not empty
find: `./refs/heads/': No such file or directory
find: `./refs/heads/': No such file or directory

我有点不知道在这里做什么 – ls -latri命令的inode信息似乎表明’heads’目录中有2个目录是head目录的硬链接

关于如何清理它的任何想法都是最受欢迎的 – 我认为我已经解决了它导致的应用程序问题,但文件系统的更大问题需要排序.

谢谢!

编辑:附加输出位:

没有隐藏的字符:

[root@node repo.git/refs]# ls -latrib heads/
total 28
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 .
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21
5551209 drwxr-xr-x. 3 git git 4096 Jun  1 22:09 ..

但是当我实际上在头部目录时,这里有一些有趣的输出

[root@node repo.git/refs/heads]# ls -latrib
ls: cannot access : No such file or directory
ls: cannot access : No such file or directory
total 12
      ? -?????????? ? ?   ?      ?            ?
      ? -?????????? ? ?   ?      ?            ?
5551210 drwxr-xr-x. 2 git git 8192 Jun  1 21:21 .
5551209 drwxr-xr-x. 3 git git 4096 Jun  1 22:09 ..

解决方法

第一:Git既不是问题的原因也不是解决问题,而是表现为ls的无意义输出.停止在文件系统上使用Git或其他工具并卸载它以避免伤害.

这看起来像是一个破碎的文件系统或破坏的挂载.尝试在客户端上卸载并重新安装文件系统.尝试完全重启客户端.尝试在另一个客户端上执行相同的安装.每次都检查ls输出以查看它是否正常.这将帮助您诊断问题是否在NFS服务器端.如果ls输出继续看起来相同,则调查和修复文件系统(fsck或其他)和/或NFS服务(重新启动与NFS相关的daemoons;如果nfsd在内核中则重新启动)需要在服务器端进行.

原文链接:https://www.f2er.com/linux/400618.html

猜你在找的Linux相关文章