From: Larry Serflaten on

"Karl E. Peterson" <karl(a)mvps.org> wrote

> > Interesting that pagefile.sys returns -1 for you when I get an Error 5 from VB5's
> > GetAttr function. Are you sure that's not some sort of artifact?
>
> I override the native GetAttr:

But that result does not match the result you'd see from a call to FindFirstFile.
The dwFileAttributes member there shows &H26 which also agrees with what
Explorer will show if you have it display the file attributes (HSA).

And, from what I can find, -1 is the value of the constant INVALID_FILE_ATTRIBUTES.

http://msdn.microsoft.com/en-us/library/aa364944(VS.85).aspx
"If the function fails, the return value is INVALID_FILE_ATTRIBUTES"

Also take note what they've used -1 for in the mobile space:
http://msdn.microsoft.com/en-us/library/aa915578.aspx
"0xFFFFFFFF indicates failure."

(From one thread found while researching, pagefile was a troublesome file because
the pagefile is memory mapped. I have not tested that assumption tho...)

So how should you cope with that? From what I can tell, you are already using
the FileAtrributes member from FindFirstFile as the Found parameter to your
VBDirInclude call, so I would think you would not see -1 as a problem in
that specific case (the DirW function). You might want to re-engineer your
GetAttr override however. Perhaps calling FindFirstFile as a back up in case
GetFileAttributes fails... ???

LFS


From: Karl E. Peterson on
Larry Serflaten wrote:
> "Karl E. Peterson" <karl(a)mvps.org> wrote
>
>> > Interesting that pagefile.sys returns -1 for you when I get an Error 5 from
>> > VB5's GetAttr function. Are you sure that's not some sort of artifact?
>>
>> I override the native GetAttr:
>
> But that result does not match the result you'd see from a call to FindFirstFile.
> The dwFileAttributes member there shows &H26 which also agrees with what
> Explorer will show if you have it display the file attributes (HSA).

Wow, yeah, you're right. I misspoke. My GetAttr override is returning -1, which as
you say means an invalid result. But FFF/FNF returns &h26 (archived/hidden/system).

> And, from what I can find, -1 is the value of the constant
> INVALID_FILE_ATTRIBUTES.
>
> http://msdn.microsoft.com/en-us/library/aa364944(VS.85).aspx
> "If the function fails, the return value is INVALID_FILE_ATTRIBUTES"

Yeah, it does, and LastDllError is showing:

32: The process cannot access the file because it is being used by another
process.

> (From one thread found while researching, pagefile was a troublesome file because
> the pagefile is memory mapped. I have not tested that assumption tho...)

Well, the pagefile is actually the area of the disk where the system writes
memory-mapped files that aren't backed by a specified file system object. This
happens a lot for IPC or other temporary purposes.

> So how should you cope with that? From what I can tell, you are already using
> the FileAtrributes member from FindFirstFile as the Found parameter to your
> VBDirInclude call, so I would think you would not see -1 as a problem in
> that specific case (the DirW function).

Right. That part's working just fine. It was the part where I was dumping
debugging info that called GetFileAttributes and causing the false reporting of the
value.

> You might want to re-engineer your
> GetAttr override however. Perhaps calling FindFirstFile as a back up in case
> GetFileAttributes fails... ???

Isn't that a bit ironic? <g> I agree, that looks like one good solution. Isn't it
odd that FFF can get that value, but the function nominally designed for that
purpose can't??? I'd sure like to know the "thinking" behind that one!
--
..NET: It's About Trust!
http://vfred.mvps.org