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?
Because
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.
Similarly, the
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.)