I have two questions:

    [*] Which is the best/fastest way to clear (filling it with 0h) a file ???
    [*] In what situation is it best to use filemapping??

Posted on 2001-09-17 03:59:32 by Delight
Depends on how/why you want to clear the file. If it's to prevent
the (very) casual snooper, deleting it is enough. Defeating most people
(with disk editors), filling it with zeroes *should* be enough. To be
"safe", you will need a *lot* more :).

Filemapping is good because it's easy to work with. BUT, there's
a limit to how much you can have mapped at once (more than 600
megabyte, less than 1.2 gigabytes) because of how windows organizes
it's memory regions. Also, memory mapping works by relying on the
page fault mechanism. Whether this is slower or faster than using
FileRead and FileWrite I do not know, but faults are sort of expensive.
Then again, there are a lot of checks inside the API calls as well, so...
my guess it it won't matter too much if you use filemapping or WriteFile stuff.

I'd go for WriteFile if you need to clear large files, otherwise you'll
have to deal with filemapping in the "windowed" way.
Posted on 2001-09-17 05:27:24 by f0dder
If you want to keep a certain big brother from knowing what you've had on your HD, a tree grinder should work fine.

I didn't know that there is a minimum size to map a file. I didn't see anything in the API help file and Iczelion's tutorial doesn't mention anything of that sort.
Posted on 2001-09-17 22:29:55 by eet_1024
There isn't a minimum size. However...

When you call CreateFileMapping, you can specify either a "maximum
file size" (64bit, so this can be quite lage). The file is grown to this
size right away, not when it "needs to". Or you can specify "0" to
use the current filesize.

In any way, you can never grow a memory mapped file (unless you
unview&unmap it, grow it, and re-map it).

Next, you MapViewOfFile. Usually you'll see a lot of parameters set
to 0 here, which means "map the entire file" (start from offset 0, and
map all bytes). This will work for files of moderate size, but because
we're limited to a 4GB address space, and because parts of the address
space are reserved for other things, this just won't work for multi-
gigabyte files.

If you look closer at MapViewOfFile, you'll see that the offset to begin
mapping is a 64bit number, and the number of bytes to map is a
32bit value. So, you can map "windows" of large files, and work
with parts of the file as needed.

... and that was the basics of file mapping :)
Posted on 2001-09-18 04:37:20 by f0dder