WIN32_FIND_DATA question

[John Madden]

Hello,

Am trying to write a program that compares a file size input from the
user to all the files the program encounters while recursing a given
directory. The recusion through the directories works fine, but my problem
is interpretting Microsoft's WIN32_FIND_DATA structure. I try to compare the
input files size to the structure's nFileSizeHigh reading. Is this the way
to go? Documentation is unclear. What I want is the program to state when
the current file in the WIN32_FILE_DATA structure is larger that the user's
input.

[Brian Poe]

From Win32 doc;

"The size of the file is equal to (nFileSizeHigh * MAXDWORD) + nFileSizeLow."

So you could use an int64 to store and compare the file sizes..

-Brian

[John Madden]

Brian:

Thanks for the info, that did the trick!

Brian Poe wrote in message <361B9C12...@flash.net>...

[Jason Boehle]

> Am trying to write a program that compares a file size input from the
>user to all the files the program encounters while recursing a given
>directory. The recusion through the directories works fine, but my problem
>is interpretting Microsoft's WIN32_FIND_DATA structure. I try to compare the
>input files size to the structure's nFileSizeHigh reading. Is this the way
>to go? Documentation is unclear. What I want is the program to state when
>the current file in the WIN32_FILE_DATA structure is larger that the user's
>input.

John,

nFileSizeHigh is only set when the file size is larger than 4GB. For 99.9%
of the files you will run into, just examining nFileSizeLow will give you
the correct file size.

Jason Boehle
jbo...@lawrence.ks.us

[Ibaidul Sahib (Abdaul)]

If you are going to use nFileSizeHigh you would have to do this:

double size=(MAXDWORD * fd.nFileSizeHigh /1024.0) +nFileSizeLow;

and then divide size by 1024.0 to obtain the correct result.

[Robert Schlabbach]

John A. Grant wrote in message <6vg0r6$58...@nrn2.NRCan.gc.ca>...
> The documentation clearly states:

>
> "The size of the file is equal to
> (nFileSizeHigh * MAXDWORD) + nFileSizeLow."

It indeed states this, however it MUST be wrong. In fact, the sentence
contradicts itself:

"nFileSizeHigh
Specifies the high-order DWORD value of the file size, in bytes. This value
is zero unless the file size is greater than MAXDWORD. The size of the file

is equal to (nFileSizeHigh * MAXDWORD) + nFileSizeLow."

The "high-order DWORD value" is (64-bit word) >> 32. To put thie original
64-bit word together, the math would be

(nFileSizeHigh << 32) + nFileSizeLow

or

(nFileSizeHigh * 0x100000000) + nFileSizeLow

MAXDWORD is #defined as 0xFFFFFFFF. That's the WRONG multiplicator. You
could correct the documented math as

(nFileSizeHigh * (MAXDWORD + 1)) + nFileSizeLow

but I'd personally prefer using the shift operator << 32...

Regards,
--
Robert Schlabbach
e-mail: rob...@powerstation.isdn.cs.TU-Berlin.DE
Technical University of Berlin, Germany

[Norman Bullen]

Robert Schlabbach wrote:
>
> John A. Grant wrote in message <6vg0r6$58...@nrn2.NRCan.gc.ca>...
> > The documentation clearly states:
> >
> > "The size of the file is equal to
> > (nFileSizeHigh * MAXDWORD) + nFileSizeLow."
>
> It indeed states this, however it MUST be wrong. In fact, the sentence
> contradicts itself:
>
> "nFileSizeHigh
> Specifies the high-order DWORD value of the file size, in bytes. This value
> is zero unless the file size is greater than MAXDWORD. The size of the file
> is equal to (nFileSizeHigh * MAXDWORD) + nFileSizeLow."
>
> The "high-order DWORD value" is (64-bit word) >> 32. To put thie original
> 64-bit word together, the math would be
>
> (nFileSizeHigh << 32) + nFileSizeLow
>
> or
>
> (nFileSizeHigh * 0x100000000) + nFileSizeLow
>
> MAXDWORD is #defined as 0xFFFFFFFF. That's the WRONG multiplicator. You
> could correct the documented math as
>
> (nFileSizeHigh * (MAXDWORD + 1)) + nFileSizeLow
>
> but I'd personally prefer using the shift operator << 32...
>

Remember also to cast the variable nFileSizeHigh to __int64; otherwise
you simply shift all of the bits off of the end.

Norm

[Raymond Chen]

On Tue, 13 Oct 1998 22:26:06 +0200, "Robert Schlabbach"
<rob...@powerstation.isdn.cs.TU-Berlin.DE> wrote:
>> "The size of the file is equal to
>> (nFileSizeHigh * MAXDWORD) + nFileSizeLow."

>MAXDWORD is #defined as 0xFFFFFFFF. That's the WRONG multiplicator.

Oops. I'll have it fixed in the next version of the SDK.
--
(My return address is intentionally invalid; delete ".---" to get my real address.
My responses are not to be considered official technical support or advice.)

[Tim Roberts]

"Ibaidul Sahib (Abdaul)" <IBAI...@xtra.co.nz> wrote:

>If you are going to use nFileSizeHigh you would have to do this:
>
>double size=(MAXDWORD * fd.nFileSizeHigh /1024.0) +nFileSizeLow;
>
>and then divide size by 1024.0 to obtain the correct result.

No, no, no! Where did you come up with this? It is not correct. You
can't divide nFileSizeHigh by 1024 and not do the same thing to
nFileSizeLow. And it is certainly not necessary to case to double to
manipulate file sizes.

Even if the "/1024.0" in that expression were omitted, which would at least
put this in the ballpark, as Robert Schlabbach correctly pointed out, the
SDK is wrong when it suggests using MAXDWORD as a multiplier.

As other posters have suggested, you need to use __int64 or LARGE_INTEGER:

LARGE_INTEGER li;
li.LowPart = fd.nFileSizeLow;
li.HighPart = fd.nFileSizeHigh;
// Now "li.QuadPart" is an __int64 with the complete 64-bit file size.

This can also be done as:

__int64 qwFileSize = ((__int64)fd.nFileSizeHigh)<<32) | fd.nFileSizeLow;

- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.