About real_size

[lema...@gmail.com]

About

    It's unclear what is real_size field needed for. It usually equals
    to. the size but may contain any value less than size (including 0

Usually on Windows (on NTFS at least), you can allocate a big file
(non-sparse) before filling it (to reduce fragmentation or ensure
enough space for example). Normally, the FS would have to fill all the
space with zeros, otherwise you could read previously deleted files
which were on the same place (this would be a security liability). But
filling with zeros is slow (and wasteful if you're going to fill the
real data later).

So what it does is having two size fields. One is the "space allocated
on disk" (size). The other one is the "valid space" (real_size).

If the application tries to read past real_size, zeros should be
returned.
If it tries to write at real_size, real_size should be increased.
If it tries to write past beyond real_size, real_size should be
increased and the gap should be filled with zeros.

It's not surprising this happens on pagefile.sys as it is usually
allocated but not initialized / filled.

Of course doing this correctly costs performance, so it's probably not
worth it (exFAT is not supposed to be a secure multiuser filesystem).

[Andrew Nayenko]

Hi,

This sounds very reasonable. MSDN describes this behavior here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365544(v=vs.85).aspx
I agree that since exFAT is an FS mostly for removable media it hardly
needs advanced security mechanisms.

Thanks for clarification!

--
Andrew Nayenko <res...@gmail.com>