我有一个目录,有两个神秘的条目,它们不显示索引节点号或任何其他元数据。当我ls -li
在命令行中输入时,我得到:
$ ls -li
ls: no s’ha pogut accedir a 'clementine.db-journal': El fitxer o directori no existeix
ls: no s’ha pogut accedir a 'clementine.db-journal': El fitxer o directori no existeix
total 1356072
# Some normal files
? -????????? ? ? ? ? ? clementine.db-journal
? -????????? ? ? ? ? ? clementine.db-journal
# more normal files
第一个?
是索引节点,下面的组是权限,一个我不知道,用户和组,文件大小和日期,最后是文件名。
rm -f clementine.db-journal
似乎没有帮助。
有没有比 ls 更低级别的目录分析工具?目录损坏了吗?我可以修复它吗?我必须替换整个目录吗? (和mkdir, cp, rm, rmdir
)
上下文信息:
我用 Clementine 来听音乐。 Clementine 使用 sqlite 数据库来存储信息。 Clementine 数据库位于~/.config/Clementine/clementine.db
。当我断电后启动时会出现此条目(我知道我需要 UPS)。它所在的文件系统是btrfs
.
编辑:
正如 @DopeGhoti 提到的,我运行了文件系统检查(相当于 btrfs)。输出如下:
$ sudo btrfs check /dev/sda6
Checking filesystem on /dev/sda6
UUID: 5ea692ab-c7b1-4618-be39-d82eaf5c6b34
checking extents
checking free space cache
checking fs roots
root 5 inode 2119729 errors 200, dir isize wrong
root 5 inode 2178458 errors 1, no inode item
unresolved ref dir 2119729 index 541 namelen 21 name clementine.db-journal filetype 1 errors 5, no dir item, no inode ref
root 5 inode 2219774 errors 1, no inode item
unresolved ref dir 2119729 index 1822 namelen 21 name clementine.db-journal filetype 1 errors 5, no dir item, no inode ref
root 5591 inode 1491275 errors 200, dir isize wrong
root 5591 inode 2076115 errors 1, no inode item
unresolved ref dir 1491275 index 984 namelen 21 name clementine.db-journal filetype 1 errors 5, no dir item, no inode ref
root 5591 inode 2119729 errors 200, dir isize wrong
root 5591 inode 2178458 errors 1, no inode item
unresolved ref dir 2119729 index 541 namelen 21 name clementine.db-journal filetype 1 errors 5, no dir item, no inode ref
ERROR: errors found in fs roots
found 810099113984 bytes used, error(s) found
total csum bytes: 789379208
total tree bytes: 1426243584
total fs tree bytes: 368427008
total extent tree bytes: 84656128
btree space waste bytes: 283686669
file data blocks allocated: 1116310724608
referenced 821686456320
很明显,这些条目造成了一些问题,但它们仍然存在。
答案1
btrfs check
只会显示问题。你需要使用btrfs check --repair
(尝试)使固定它发现的问题。 然而,大多数文档建议反对使用--repair
。但是,由于确实btrfsck
暴露了损坏文件的索引节点,因此可以使用例如删除它们find / -inum XXXX -delete
(XXXX
用实际损坏的索引节点替换)。
如果你想真正尝试恢复文件,这比我使用 btrfs 的工资等级要高一点,但是作者这个答案也许能够为您指明正确的方向。
答案2
我在使用不同的文件(来自 .mozilla 的 prefs.js)时遇到了完全相同的问题。
这是 Fedora 28,btrfs-progs 4.15.1
我最终以单一用户身份使用工作站,确保文件系统已卸载并btrfs check --repair
在文件系统上运行。幸运的是,这是一个虚拟机,所以我能够先对文件系统进行快照。
修复按预期进行,最终删除了错误附加到同一文件条目的数百万个索引节点。我不知道是什么导致了这个问题,但修复过程适用于这个特定的错误。