About System Folder Compression - China DOS Union Forum - China DOS Union

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 ]

Floor1　willsort	Posted 2006-03-23 20:51
元老会员　Posts 1,512　Credits 4,432
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 ]

Floor2　Wengier	Posted 2006-03-24 00:55
系统支持　Posts 10,521　Credits 27,736
Copying does not retain the compression attribute, which is similar to the characteristics of the inode under Unix. If after copying, it is equivalent to generating new data, which is no longer related to the previous inode, so the original compression attribute no longer exists; while moving only changes the link pointer, and the inode remains the same, so its compression attribute remains unchanged.

Floor3　fujianabc	Posted 2006-03-24 11:22
金牌会员　Posts 1,616　Credits 3,467
This compression function emerged with the appearance of NTFS and has been around for a long time. NTFS compression is a compression algorithm that pursues speed rather than compression ratio. I remember that when NTFSdos is loaded under DOS, you can choose not to support NTFS compression. For an NTFS volume, all files except ntldr can be compressed, but if ntldr is compressed, the system cannot boot. If you want to see the "original state" after NTFS compression, you can use some disk editing software to view.

Floor4　6622186	Posted 2007-04-24 05:27
高级用户　Posts 411　Credits 894
At first, I compressed it, but found that the file itself didn't get smaller, only the color changed and it was transparent when accessed. I was always puzzled. Later, I searched online and then right-clicked the file properties and found that the occupied space did become smaller, then I understood the reason.

Floor5　6622186	Posted 2007-04-24 05:29
高级用户　Posts 411　Credits 894
NTFS stands for the new features of NT

Floor6　lpk130	Posted 2007-04-24 05:55
初级用户　Posts 30　Credits 80
The new features of NTFS also include EFS encryption. These operations are all transparent to users.

Floor7　06403213	Posted 2007-10-07 02:09
初级用户　Posts 21　Credits 42
Today I also discovered this problem, and I went to the DOS Union forum to search and found this post, which is also similar to my understanding. Does "compression is transparent" mean that after compression, it can be used without decompression? The allocation unit of such disk compressed files is still based on clusters, that is, multiples of 4096. Only compressed files do not abide by this. I don't really understand. Is there any expert who can explain the technology of disk compression? I'm really confused.