Bill Todd wrote:
mike wrote:
Bill Todd wrote:
Maxim S. Shatskih wrote:
I don't think he wants to take the time to zero (or otherwise
write) the actual file data. ISTR that an (undocumented?) API
exists to

SetEndOfFile, it is documented.

Indeed, and that's clearly the right approach since it seems to
accomplish what's desired using a documented interface. But it was
not what I was remembering (see my other reply).

- bill

I have two problems writing code. I'm lazy.
And I have no idea what I'm doing.
I found a VB6 code example and hacked it as follows:

Private Sub Command1_Click()
Path = "x:\big1.txt"
hFile = CreateFile(Path, GENERIC_WRITE, FILE_SHARE_READ Or
FILE_SHARE_WRITE, ByVal 0&, OPEN_ALWAYS, 0, 0)
If hFile = -1 Then End
WriteFile hFile, ByVal "Very-very cool & long string", 28,
BytesWritten, ByVal 0&

SetFilePointer hFile, 900000000, 0, FILE_BEGIN
SetEndOfFile hFile
CloseHandle hFile
...

This does make a big file, but it fills the file with zeros
and takes 18 minutes to do it.
Am I using the wrong arguments?

It's possible that you're just using the wrong OS: I did find one
reference that says that with Win2K and earlier systems SetEndOfFile
zeros the space allocated, whereas with XP and later it does not
(because ValidDataLength protects the garbage in what's been allocated
from being read until it has been over-written: I thought that was true
in Win2k as well, but I may have been mistaken - and indeed the MSDN
documentation states that SetFileValidData only exists in XP and Vista,
but the internal ValidDataLength guard existed at least as early as
Win2K and thus there really would be no *need* for SetEndOfFile to zero
allocated space there).

- bill
I'm testing it on an XP system. I am running it from within the VB6
environment. Could that make a difference?
Should compile it and try again.
But I really do want to run it on a win2k laptop.
mike

--
Return address is VALID!