To All:
很早就注意到,在Windows系统目录下,类似“$NtUninstallKB885835$”的更新程序卸载备份文件夹的名字是蓝色的,只是一直无暇追究其中的缘由,想来不过是彰显文件夹的某些特殊属性而已。
最近,开始清理系统盘空间,偶然发现在这些蓝色名字的目录有个奇怪的特性,即在右键属性菜单中的常规选项卡中,文件的<占用空间>总是小于文件的<实际大小>,而这与我脑中的占用空间比不小于文件大小的常规知识向矛盾。
因为在FAT和NTFS文件系统中,文件以簇的形式占用磁盘空间,文件大小的不规则导致它很可能无法将所使用的簇恰好占满,而某些簇中的剩余空间因为无法收集而被废弃,因此文件的占用即为文件所用簇的占用空间,它必然是1024或其他大小(XP为4096)的整数倍,也因此它必然大于等于文件的实际大小。
不解之余,上百度搜索答案,不久即赧然一笑,却原来是压缩后的文件夹,使用的乃是属性菜单常规选项卡“高级”选项对话框中的“压缩”功能。所有使用“压缩”的文件或文件夹名字均为蓝色,既已压缩,占用空间小于实际大小的谜底也就揭开了。
但是不久,新的疑惑就接踵而来,我做了一些简单的测试:如果将这个压缩文件(夹)复制到其它目录下,则不再具有压缩特性;如果将这个压缩文件(夹)移动到其它目录下,则压缩特性保留;而如果将这个压缩文件(夹)复制后再移动的相同的目录下,则移动特性消失。由此移动结果推断,“压缩”应属于文件或文件夹自有的一种“属性”,但它却为何无法通过复制进行传递?
另外的一些测试表明,此种压缩的压缩率很低,一个2M的文本文件压缩后还有1.8M,而使用WinRAR可以压到0.8M,而它对使用WinRAR压缩过的文件会自动选择不再压缩,依此推测系统的压缩算法是牺牲压缩率来换取压缩速率。
还有的一点发现,或者说“未发现”,就是系统的解压过程对于我所测试的任何测试都是透明的,即使是在CMD或者COMMAND环境下,也可以正确无误的浏览压缩后的文本文件。没有在DOS下测试,因为是NTFS卷,若使用外部驱动支持,就无法真正得知其是否完全透明了,因为我无法断定,NTFS的DOS驱动是否也会透明的解压。而且在Windows下找到它的压缩后的“原始状态”似乎更有意义。
[ Last edited by willsort on 2006-3-23 at 21:06 ]
很早就注意到,在Windows系统目录下,类似“$NtUninstallKB885835$”的更新程序卸载备份文件夹的名字是蓝色的,只是一直无暇追究其中的缘由,想来不过是彰显文件夹的某些特殊属性而已。
最近,开始清理系统盘空间,偶然发现在这些蓝色名字的目录有个奇怪的特性,即在右键属性菜单中的常规选项卡中,文件的<占用空间>总是小于文件的<实际大小>,而这与我脑中的占用空间比不小于文件大小的常规知识向矛盾。
因为在FAT和NTFS文件系统中,文件以簇的形式占用磁盘空间,文件大小的不规则导致它很可能无法将所使用的簇恰好占满,而某些簇中的剩余空间因为无法收集而被废弃,因此文件的占用即为文件所用簇的占用空间,它必然是1024或其他大小(XP为4096)的整数倍,也因此它必然大于等于文件的实际大小。
不解之余,上百度搜索答案,不久即赧然一笑,却原来是压缩后的文件夹,使用的乃是属性菜单常规选项卡“高级”选项对话框中的“压缩”功能。所有使用“压缩”的文件或文件夹名字均为蓝色,既已压缩,占用空间小于实际大小的谜底也就揭开了。
但是不久,新的疑惑就接踵而来,我做了一些简单的测试:如果将这个压缩文件(夹)复制到其它目录下,则不再具有压缩特性;如果将这个压缩文件(夹)移动到其它目录下,则压缩特性保留;而如果将这个压缩文件(夹)复制后再移动的相同的目录下,则移动特性消失。由此移动结果推断,“压缩”应属于文件或文件夹自有的一种“属性”,但它却为何无法通过复制进行传递?
另外的一些测试表明,此种压缩的压缩率很低,一个2M的文本文件压缩后还有1.8M,而使用WinRAR可以压到0.8M,而它对使用WinRAR压缩过的文件会自动选择不再压缩,依此推测系统的压缩算法是牺牲压缩率来换取压缩速率。
还有的一点发现,或者说“未发现”,就是系统的解压过程对于我所测试的任何测试都是透明的,即使是在CMD或者COMMAND环境下,也可以正确无误的浏览压缩后的文本文件。没有在DOS下测试,因为是NTFS卷,若使用外部驱动支持,就无法真正得知其是否完全透明了,因为我无法断定,NTFS的DOS驱动是否也会透明的解压。而且在Windows下找到它的压缩后的“原始状态”似乎更有意义。
[ Last edited by willsort on 2006-3-23 at 21:06 ]
