To All：
I've long noticed that in the Windows system directory, the names of update program uninstall backup folders like "$NtUninstallKB885835$" are blue. I just never had time to find out why, thinking it was just to highlight some special properties of the folder.
Recently, when I started cleaning up space on the system drive, I accidentally noticed a strange feature in these blue-named directories: in the General tab of the right-click Properties menu, the <Occupied Space> of the file is always smaller than the <Actual Size>, which contradicts my usual knowledge that occupied space is not smaller than file size.
Because in FAT and NTFS file systems, files occupy disk space in clusters. The irregular file size means it may not exactly fill the used clusters, and some remaining space in clusters is discarded because it can't be collected. So the occupied space of a file is the occupied space of the clusters it uses, which must be an integer multiple of 1024 or other sizes (4096 for XP), so it must be greater than or equal to the actual size of the file.
After being confused, I searched on Baidu and soon smiled in embarrassment. It turned out to be a compressed folder, using the "Compress" function in the Advanced option dialog of the General tab in the Properties menu. All files or folders using "Compress" have blue names, and the mystery that occupied space is smaller than actual size is solved.
But soon, new doubts followed: I did some simple tests: if I copy this compressed file (folder) to another directory, it no longer has the compressed feature; if I move this compressed file (folder) to another directory, the compressed feature is retained; and if I copy and then move this compressed file (folder) to the same directory, the moved feature disappears. From the movement results, "Compress" should be a kind of "attribute" of the file or folder, but why can't it be transferred through copying?
Other tests show that this kind of compression has a very low compression ratio. A 2M text file is still 1.8M after compression, while WinRAR can compress it to 0.8M, and it will automatically choose not to compress files compressed with WinRAR. This suggests that the system's compression algorithm sacrifices compression ratio for compression speed.
Another discovery, or "non-discovery", is that the system's decompression process is transparent to any tests I did. Even in the CMD or COMMAND environment, I can correctly browse the compressed text file. I didn't test it under DOS because it's an NTFS volume. If external drive support is used, I can't really know if it's completely transparent because I can't be sure if the NTFS DOS driver will also decompress transparently. And it seems more meaningful to find its "original state" after compression under Windows.
Last edited by willsort on 2006-3-23 at 21:06 ]
