Share via

Differences in NTFS compression between the Windows Explorer and COMPACT based on new XPRESS4K/XPRES8K/XPRESS16K/LZX algorithms

Question

Wednesday, November 23, 2016 12:26 PM

Howdy,

Many of us know there are new compression options available in COMPACT tool on Windows 10. These options are used specifically to compress PE files.

Here they are all together sorted from low to high level of compression:

  • XPRESS4K
  • XPRESS8K
  • XPRESS16K
  • LZX

All the options represent a specific compression algorithm.

The command to compress files is as follows:

compact /exe:lzx /c /f %filepath%

How is the result of using COMPACT with these options different from using NTFS compression?

Some sources say that what COMPACT does is different from what the Compress contents to save disk space option in Windows Explorer does.

Indeed, it looks like the difference is when Compress contents to save disk space enables NTFS compression that uses compression units (CU), COMPACT uses sparse files.

However, NTFS compression does not support compression on file systems where cluster size is greater than 16 Kbytes. If using

C:\WINDOWS\system32>fsutil fsinfo ntfsinfo c:

shows you that Bytes Per Cluster is more than 16384 bytes, native NTFS compression won't work and Compress contents to save disk space will be unavailable in file or folder properties.

Here's where you can use COMPACT to compress files and folders on NTFS. Despite what official documentation says about COMPACT

The compact command, the command-line version of the NTFS file system compression feature,

COMPACT is not the command-line version of NTFS file system compression as it uses sparse files.

Since compact arranges data into CUs and makes NTFS to actually read data in CU chunks, it looks like the more compressed data you have, the quicker is random access. It this true?

Could somebody please clarify why won't I always use /exe:lzx on office computers? Say, it looks reasonable to always compress %programfiles%\Microsoft Office\ and %programfiles (x86)%\Microsoft Office by using COMPACT. Indeed there isn't many large files, so compression won't result in many fragments, most of the data is PE files, so using LZX is highly effective and, lastly, there aren't many write operations (or are there?) for the files of Office suite.

To me it looks like compressing office files by using COMPACT will always contribute for quicker start of Office applications and help reduce the space at the same time. Am I wrong? If so, where?

Thank you.

Well this is the world we live in And these are the hands we're given...

All replies (2)

Wednesday, November 23, 2016 12:37 PM

Just an example. Let's consider the %ProgramFiles%\Microsoft Office\Office16\Uc.dll library.

ORIGINAL

Size: 39,448,384 bytes

Compression ratio: 39448384 :  39448384 = 1,0 to 1

REGULAR NTFS COMPRESSED

Info: Compressed by using NTFS compression (the Compress contents to save disk space option), block size **4K **

Size: 21,204,992 bytes

Compression ratio: 39448384 :  21204992 = 1,9 to 1 C

Note the C attribute, it's compressed, not sparse compressed.

SPARSE COMPRESSED

  • XPRESS4K:
    18,288,640 bytes
    39448384 :  18288640 = 2,2 to 1
compact /exe:xpress4K /c /f "C:\Program Files\Microsoft Office\Office16\Uc.dll"
  • XPRESS8K:
    16,617,472 bytes
    39448384 :  16617472 = 2,4 to 1
compact /exe:xpress8K /c /f "C:\Program Files\Microsoft Office\Office16\Uc.dll"
  • XPRESS16K:
  • 15,704,064 bytes
    39448384 :  15704064 = 2,5 to 1
compact /exe:xpress16K /c /f "C:\Program Files\Microsoft Office\Office16\Uc.dll"
  • LZX:
    12,001,280 bytes

       39448384 :  12001280 = 3,3 to 1

compact /exe:lzx /c /f "C:\Program Files\Microsoft Office\Office16\Uc.dll"

Well this is the world we live in And these are the hands we're given...

Wednesday, April 1, 2020 2:23 PM

Hi, this is amazing! Why not to compress this way all folders in the Program Files folder? I just tested it on Adobe Reader DC and it did great job. The compression ration was 2.3 to 1.

Can somebody explain the magic behind? The OS shows the file with the same size like before but when I check properties the size on disk is the compressed size.

Perhaps one drawback?! The Option /C of Compact.exe says:

Compresses the specified files.  Directories will be marked so that files added afterward will be compressed  unless /EXE is specified.

So, what happens when Acrobat installs an update? Would it be necessary to compress the whole folder again?

Performance wise it seems that there is no Impact. Perhaps Acrobat started faster than before.

Thanks