If I want to know when a file was created, what size is it, and so on,
without opening it, what API should I use?
Could anyone post an example of calling the API and getting the info
from the file?
Thanks
Frank
FindFirstFile (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx) will get all of that information.
Quote from: Donkey on December 24, 2012, 01:10:01 PM
FindFirstFile (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx) will get all of that information.
Thanks Edgar.
It seems other APIs as well give the same info:
GetFileTime(), GetFileInformationByHandle() among them.
I'll give them a try.
you might also like GetFileAttributesEx :P
it gives you the 3 file times, the attribute, and the size
and, it's fast
Quote from: dedndave on December 24, 2012, 01:45:09 PM
you might also like GetFileAttributesEx :P
it gives you the 3 file times, the attribute, and the size
and, it's fast
It looks like all the APIs give all these info. Which one is faster I can't tell.
I suppose all of them are quite fast.
:P
i use GetFileAttributesEx - normally i just want the file size - sometimes the attribute also
in the old forum, we did some testing and it was fastest
however, i think that test was "what is the fastest way to get file size"
it did not take the other data into account
as i recall, FindFirstFile was slowest
Quote from: dedndave on December 24, 2012, 03:47:02 PM
i use GetFileAttributesEx - normally i just want the file size - sometimes the attribute also
in the old forum, we did some testing and it was fastest
however, i think that test was "what is the fastest way to get file size"
it did not take the other data into account
as i recall, FindFirstFile was slowest
Dave, if you have an example of getting file info with GetFileAttributesEx
and display date of last write, and file size, it'd be nice.
I've seen some examples using the stack, posted by you and Jochen, but
I'd prefer the use of the structure as it is declared.
Messing with the stack is not my actual priority. :biggrin:
just for info....
GET_FILEEX_INFO_LEVELS is an enumeration type
MASM does not have an exact replacement for enumerations
it's sort of like a cross between a structure and an equate
GetFileExInfoStandard is the first enumeration member, so the value is 0 - it's the only valid value
give me a second.....
Quote from: dedndave on December 25, 2012, 12:34:01 AM
MASM does not have an exact replacement for enumerations
MASM has lots of crazy stuff ;-)
Enum IdMenuNew, IdMenuSave, IdMenuCopy, IdEdit, IdList, IdButton, ...
SetGlobals hInstG, hMain, hList, rc:RECT, ...
give this a try
Usage:
FileInfo <filename>
C:\Masm32\Asm>FileInfo blah
File Not Found
C:\Masm32\Asm>FileInfo
No File Specified
C:\Masm32\Asm>FileInfo FileInfo.asm
nFileSize: 00000000000019E1h
ftCreationTime: MON 12-24-2012 13:23:29.927
ftLastAccessTime: MON 12-24-2012 14:47:16.630
ftLastWriteTime: MON 12-24-2012 14:46:13.380
FILE_ATTRIBUTE_ARCHIVE
C:\Masm32\Asm>FileInfo C:\Windows
nFileSize: 0000000000000000h
ftCreationTime: WED 2-23-2005 11:59:56.609
ftLastAccessTime: MON 12-24-2012 14:51:19.177
ftLastWriteTime: SUN 12-23-2012 16:46:53.6
FILE_ATTRIBUTE_DIRECTORY
EDIT: updated the attachment
fixed the command line parser
improved the way carriage return/line feeds are used
Quote from: dedndave on December 25, 2012, 01:48:32 AM
give this a try
Usage:
FileInfo <filename>
C:\Masm32\Asm>FileInfo blah
File Not Found
C:\Masm32\Asm>FileInfo
No File Specified
C:\Masm32\Asm>FileInfo FileInfo.asm
nFileSize: 00000000000019E1h
ftCreationTime: MON 12-24-2012 13:23:29.927
ftLastAccessTime: MON 12-24-2012 14:47:16.630
ftLastWriteTime: MON 12-24-2012 14:46:13.380
FILE_ATTRIBUTE_ARCHIVE
C:\Masm32\Asm>FileInfo C:\Windows
nFileSize: 0000000000000000h
ftCreationTime: WED 2-23-2005 11:59:56.609
ftLastAccessTime: MON 12-24-2012 14:51:19.177
ftLastWriteTime: SUN 12-23-2012 16:46:53.6
FILE_ATTRIBUTE_DIRECTORY
When I type "FileInfo FileInfo.asm" in the command line,
It just says : "File Not Found".
Dave what's going on?
is it in the current folder ?
if not, you must specify the full pathname
also - i made a little mistake in the command-line parser
if you put more than one space in there, it will fail :P
updated the previous attachment
Quote from: dedndave on December 25, 2012, 12:18:11 PM
is it in the current folder ?
if not, you must specify the full pathname
also - i made a little mistake in the command-line parser
if you put more than one space in there, it will fail :P
updated the previous attachment
:t
Now it works. I'll see if I can understand something.
here is one with a more advanced parser
it will accomodate use in batch files where you need to surround paths containing spaces by double-quotes
C:\Masm32\Asm>"FileInfo" "C:\Program Files"
nFileSize: 0000000000000000h
ftCreationTime: WED 2-23-2005 12:4:1.921
ftLastAccessTime: TUE 12-25-2012 3:35:33.640
ftLastWriteTime: MON 12-24-2012 3:18:21.427
FILE_ATTRIBUTE_READONLY
FILE_ATTRIBUTE_DIRECTORY
From what I remember, GetFile... function sometimes (mostly?) fail for system critical files like pagefile.sys, hiberfil.sys, etc. FindFirstFile works in such cases.
Typically what I used to do was (don't remember where the code is now) to write a wrapper function with my own naming convention, logging messages etc., which internally calls FindFirstFile. Even if it is just for a single file! :biggrin: :icon_eek:
HTH,
Shantanu
thanks for the tip Shantanu :t
GetFileAttributesEx seems to work on boot.ini, but not pagefile.sys
it even works on C:\ :P
what you could do is use GetFileAttributesEx for speed
if that fails, then use FindFirstFile to verify whether or not the file really exists
typically, when i use GetFileAttributesEx, i am using it on a config file or some other similar data file, though
Probably I'm not going to use these functions on critical
files, but it is good to know anyway that on some files
the functions can fail.
Thanks and Happy Holidays.
i played with it anyways
the WIN32_FIND_DATA structure is a superset of the WIN32_FILE_ATTRIBUTE_DATA structure
so - the code is pretty simple
while i was at it, i made some more improvements on the parser
i made sure to use LODSB, just for Hutch (http://l.yimg.com/us.yimg.com/i/mesg/emoticons7/4.gif)
C:\>"documents and settings\fileinfo" "c:\pagefile.sys
nFileSize: 000000005F400000h
ftCreationTime: MON 12-10-2012 0:23:34.390
ftLastAccessTime: TUE 12-25-2012 13:32:44.125
ftLastWriteTime: TUE 12-25-2012 13:32:44.125
FILE_ATTRIBUTE_HIDDEN
FILE_ATTRIBUTE_SYSTEM
FILE_ATTRIBUTE_ARCHIVE
the reason i spent time on this is i will use the parse code for future projects
and - it gave me a break from my "big" project - back to that tomorrow :P
For a test of the relative speeds of those functions try to get the file information over a network.
This will give you an idea of overhead :lol:
that latest version uses FindFirstFile only if GetFileAttributesEx fails
really, you have to tailor your code for the specific application, as always
Quote from: dedndave on December 26, 2012, 02:52:42 PM
that latest version uses FindFirstFile only if GetFileAttributesEx fails
really, you have to tailor your code for the specific application, as always
Well done, Dave :t
FFF finds the *.sys files. As to speed, FindFirstFile is a bit slower because, as the name says, it first has to find the file that matches e.g. *.doc - and that costs time. I have difficulties to construct a real life case where the speed difference matters, i.e. where you have already a complete list of 100,000 files and you still need further info...
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init ; ### show files in C:\* ###
GfNoRecurse=1 ; root only
GetFiles C:\*
xchg eax, ecx
Print "Files in the root:"
.Repeat
PrintLine Files$(ecx)
dec ecx
.Until Sign?
Inkey
Exit
end start
Files in the root:
C:\pagefile.sys
C:\ntldr
C:\NTDETECT.COM
C:\MSDOS.SYS
C:\IO.SYS
C:\install.ini
C:\hiberfil.sys
C:\globdata.ini
C:\CONFIG.SYS
C:\Bootfont.bin
C:\boot.ini
C:\AUTOEXEC.BAT
Quote from: jj2007 on December 27, 2012, 04:56:25 AM
FFF finds the *.sys files. As to speed, FindFirstFile is a bit slower
because, as the name says, it first has to find the file that
matches e.g. *.doc - and that costs time. I have difficulties
to construct a real life case where the speed difference matters,
i.e. where you have already a complete list of 100,000 files and
you still need further info...
Thanks Jochen for the explanation.
In this case, and for a rare coincidence, I'm not looking
for the fastest API, but just for the suitable ones.