Since it's always bugged me that the AutoIT implementation of 'FindFirstFile' and 'FindNextFile' only returned filenames and that extra calls had to be made to get file-size, attributes, short-names, and date/time of file creation,last-access, & last-modification which severely increased the amount of time it took to properly analyze the contents of a folder and it's files, I decided to create an alternative.

This uses the same Windows calls as AutoIT, except it returns all the information that it rightfully should for each file found - including:
  • File attributes (in numerical form, not a silly string format)
  • Creation Time
  • Last-Access Time
  • Last-Write Time
  • FileSize
  • Filename (obviously)
  • 8.3 short name (if it is 1. different from the regular Filename and 2. if short-names haven't been turned off
  • Reparse Point info (if available)
Now, the calling process is a little different, though for the most part not much is required to be altered in existing code. Basically, the attributes-check for folders is a numerical test, and when a folder is found, you *need* to test for '.' and '..' navigation (fake) folders. Also, the 'While' loop changes into a 'Do-Until' loop.  Additionally, the first _FileFindExFirstFile() call returns a file, whereas FileFindFirstFile() doesn't (which never made sense to me).

To convert times into a readable format, you'll need to pass the array to the _FileFindExTimeConvert() function. Optionally, you can get the _WinTimeFunctions UDF and call those functions using array index constants:

Note all _FileFindEx* calls are done using a special array, though 'ByRef' for quicker performance.

A nice application I found for this UDF was comparing files/folders - which is pretty easy using 64-bit filetime and file-size comparisons (no need for time conversion there).

The ZIP includes 4 files: the _FileFindEx UDF, FileFindExTest, the license agreement (same as below), and _LinkedOutputDisplay.  Please note that _LinkedOutputDisplay on its own is a mess - but its included as-is to help see a side-by-side comparison of the output from FileFindExTest.

To get all the same information that _FileFindEx provides, the AutoIt functions below would need to be called:
  • FileFindFirst/NextFile
  • FileGetAttrib *** NOTE: This Fails to report on some attributes (Reparse Points, Sparse Files) ***
  • FileGetTime *3 (one for each time - Creation, Last-Access, Last-Modified)
  • FileGetSize
  • FileGetShortName (note: this provides a full path, rather than just a file name)
Please note that for a fair time comparison, a clean boot is needed for each test due to O/S buffering after a scan.  Between boots, the order of function calls in 'FileFindExTest' would need to be swapped.  In first-run tests, _FileFindEx has consistently been quicker when gathering more than basic filename info.  However, running the UDF in 64-bit mode on Vista+ O/S's results in slower performance, hence this note:

*IMPORTANT* - Speed is severely affected when the script is run in x64 mode. I therefore recommend running/compiling the code in x86 (32-bit) mode.

Update Log:
- 5/24/2011: Further speed optimization when using _FileFindExTimeConvert().
- 5/23/2011: New name, faster execution!
* Removed: _WinTimeFunctions UDF.  No longer needed (see below).
* Added: New array element for REPARSE Points that are located ($aFind[7]).
* Added: Internal time-conversion function removes the need for _WinTime* calls. This results in a solid increase in performance.
* SCRIPT-BREAKING CHANGES *: Function-names changed - A simple search&replace should work here.

- 5/9/2010: New version with better 64-bit FileTime support, bundled separate example with output display, and the _WinTimeFunctions required module (+ example use).  All code falls under the same License agreement! AutoIT v3.3.6+ required.
- Updated for AutoIT v3.3 support (or UNICODE-only)

Ascend4nt's AutoIT Code License agreement:
While I provide this source code freely, if you do use the code in your projects, all I ask is that:
  1. If you provide source, keep the header as I have put it, OR, if you expand it, then at least acknowledge me as the original author, and any other authors I credit
  2. If the program is released, acknowledge me in your credits (it doesn't have to state which functions came from me, though  again if the source is provided - see #1)
  3. The source on it's own (as opposed to part of a project) can not be posted unless a link to the page(s) where the code were retrieved from is provided and a message stating that the latest updates will be available on the page(s) linked to.
  4. Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.
A Scendant,
May 24, 2011, 3:54 AM