我正在使用 Thunar 1.6.3,目前当我查看一堆文件夹时,它看起来像这样:
Folder 1 8,2 kB
Folder 2 4,1 kB
Folder 3 4,1 kB
Folder 4 0 kB
我不确定这些“大小”数字从何而来,但我确信它们不能反映文件夹中所有内容的实际大小,因为当我右键单击并选择“属性”时,文件夹(所有文件夹的大小都只有千字节)加起来超过 100 Gb。
问题
- 为什么 Thunar 和 12.04 和 14.04 上的命令行一样,显示文件夹大小为 4K?这个数字是什么意思?
- 有没有办法在终端、Thunar 或任何其他文件管理器中显示复合大小,即计算文件夹和所有内容的递归大小?(注意:我不是在寻找 shell 脚本解决方案)。
答案1
我应该解释一下 Linux 文件系统结构来解释这一点。大多数 Linux 文件系统都做了类似的事情,但我假设 ext4 是当前的默认文件系统。
文件系统结构
- inode 是文件系统理解为逻辑单元的基本块。
- 目录 inode 包含对其他 inode 的引用。
- 文件 inode 包含元数据、实际数据和对连续块的引用,以防文件必须以非连续的方式存储。
链接
- Ext4 支持两种链接:硬链接和软链接。
- 硬链接是直接引用 inode。每个文件至少有一个硬链接,来自其所属的目录。
- 由于目录只是一个 inode,带有一组 inode 引用信息,因此它可以引用自身或父级。换句话说,一个文件夹可以同时是同一文件夹的子文件夹和父文件夹。
好吧,这可能有点令人困惑。让我解释一下。假设您有三个文件夹,A、B、C,如下所示。
C is in B.
B is in A.
现在,有趣的是,C 可以指向与 A 相同的 inode,从而形成有时称为循环引用循环的情况。如果您尝试递归,您将遇到永无止境的循环。
- 软链接是记录目标位置的目录路径的普通文件。它们只是在文件系统上标记,而不是一行文本,它们应该被解释为指向其他位置的链接。例如,当您使用 Nautilus 的“创建链接”/“链接至此处”选项时,它会创建软链接。
所以呢?
因此,尝试以递归方式计算大小有其怪癖。默认情况下尝试以递归方式计算大小不是一个好主意。但是,据我所知,所有像样的文件管理器的属性对话框都显示以递归方式计算的总大小,因为这是普通用户的期望。
Windows没问题吗?
实际上,Windows 使用一种不同的文件系统格式,称为 NTFS,它维护所有文件及其大小的列表。因此它总是可以轻松知道总大小。
那我们为什么不使用NTFS呢?
它不支持 Unix 的权限概念(rwx
分别为所有者、组和范围),这个原因使其不适合用作 Linux 文件系统。Ext4 带来了很多好处,因此这个小小的不便对很多人来说并不重要。
好的。给我我需要的尺寸。
你试过了du
吗 ?
怎么du
運作?
du
代表磁盘使用情况。它实际上计算 inode 块,注意不要重复计算。将大小相加,即可得到总大小。
总结
用于du -hs <foldername>
查找磁盘上文件夹的实际大小。阅读man du
更多信息。
答案2
在图纳尔顶部菜单转到编辑>配置自定义操作,添加一个新的自定义操作:
- 基本的标签:任何名称 [例如文件夹-文件大小]、命令
du -h -c %N | grep total | zenity --text-info
或du -chs %N | zenity --text-info
所选文件夹或/和文件大小,后跟总大小。 - 外观状况标签:选中所有框。
我发现这个解决方案http://crunchbang.org
答案3
关于 Thunar 的这个主题,有一点小知识是,Thunar 报告的大小与 du 报告的大小不同,无论是否使用 --apparent size 选项。我认为 du 提供的答案暗示了为什么会这样(也许 Thunar 实际上对这些相同事物的计算方式略有不同,无论具体情况如何)。示例:同一个文件夹:(x 是余数,我没有记下来)du 未使用 --apparent-size:19.x GB du 使用了 --apparent-size:12.x GB Thunar 5.5x GB 括号中的 Thunar 值:5.9x GB 我可能最终会采用 du 的输出(因为它已经很旧了),但这仍然很有趣。