A customer reported that when they called
GetFileAttributes on a ZIP file, the
FILE_ attribute was not returned. But ZIP files are compressed. Why isn't the
FILE_ attribute being set?
FILE_ tells you whether the file was compressed by the file system. It is not a flag which describes the semantics of the bytes stored in the file. After all, the file system doesn't know that this particular collection of bytes is a ZIP file and contains data that was compressed externally. Who knows, maybe it's just some uncompressed file that just happens to look superficially like a ZIP file (but isn't)?
If a text file consists of the string "ADTUR ADKUH", is this a compressed file? Maybe it's somebody's product key, in which it isn't compressed. Or maybe it is short for "Await instructions before taking further action. Acknowledge receipt of this telegram by wire." That's an example of a commercial code, used to save telegram transmission costs by compressing frequently-used business phrases into five-letter pseudo-words.
The file system doesn't try to figure out whether a particular sequence of bytes it has been asked to store was externally compressed. It just stores the bytes on disk, perhaps after performing its own internal compression, and if that internal compression was performed (even if it didn't actually result in any compression), the
FILE_ attribute is set.
FILE_ attribute is set if the file contents were encrypted by the file system. If encryption took place externally, then the attribute is not set because the file system doesn't know that the byte sequence it was asked to store represented encrypted data.
(Note that many special-purpose file formats, such as DOCX, JAR, JPG, and PNG, are internally compressed, even though they are not advertised as such.)