Hi,
"WOF compression" is as good as the other names. It still seems slightly
wrong
because WOF (the "Windows Overlay Filesystem Filter") is a more general
feature,
and this is actually the *second* compression technology that Microsoft has
built on top of it (the first was "WIMBoot"). For now, I'll keep the code
the
way it is, using the "system compression" name. It could be that Microsoft
will
release more documentation for this.
Yes, your reparse data indicates XPRESS4K compression (the fourth 32-bit
little
endian word is 0). FYI, here are the compressed sizes I get with the
Silesia
corpus (uncompressed size: 211,938,580 bytes total):
LZNT1 (NTFS compression): 121,049,088 bytes
XPRESS4K: 104,124,416 bytes
XPRESS8K: 95,465,472 bytes
XPRESS16K: 90,460,160 bytes
LZX: 69,144,576 bytes
Even though FUSE makes big reads, it would be nice to not have to allocate a
decompression context for every read. That would avoid doing all of the
following on a per-read basis:
- open WofCompressedData attribute
- allocate heap memory for ntfs_system_decompression_ctx
- allocate heap memory for XPRESS or LZX
- read chunk offsets from the compressed file's chunk table
Having an external tool to create "system compressed" files, if people want
that
support, is probably the way to go. Probably that would be possible even
with
no changes in libntfs-3g.
Eric
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
