_FileFindEx - Get More from File/Folder Searches

[Ascend4nt 118]

_FileFindEx

Get More from File/Folder Searches

(formerly _WinAPI_FileFind)

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:

$FFX_CREATION_TIME, $FFX_LAST_ACCESS_TIME, or $FFX_LAST_MODIFIED_TIME.

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 on certain processors when the script is run in x64 mode. I therefore recommend running/compiling the code in both bit-modes beforehand to see what the speed difference is. On my machine I've found x86 is much faster, whereas x64 is much slower than AutoIt's search functions. Other's have so I'm guessing it must be how optimized the hardware architecture is at running x64 code.

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 3.2.12.1 UNICODE-only)

Download the ZIP Here

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:

• 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
• 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)
• 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.
• Pieces of the code can however be discussed on the threads where Ascend4nt has posted the code without worrying about further linking.

Edited September 26, 2011 by Ascend4nt

[ptrex 79]

@ascendant

Very nice and fast function.

But errors will come up when running this with newer Au3 version this has been removed "@AutoItUnicode" !

Regards

ptrex

[FireFox 255]

@ascendant

Great and useful job !

Five stars from me

Cheers, FireFox.

[Ascend4nt 118]

Thanks guys =)

@ptrex - that really annoys me that they removed that, arghh.. I'm still clinging to 3.2.12.1, even though I haven't found myself coding for anything ANSI lately, and I keep modifying the 3.2.12.1 WinAPI functions to include error handling hehe. I guess I should just make the switch and never look back!

Win9x oh how I will miss you..

[AlmarM 19]

Woah, looks great!

Nice work here ^^,

AlmarM

[KaFu 184]

Another cool post ascendant ! Will for sure utilize this in SMF!

Cheers

[Ascend4nt 118]

Heh, I'd be honored to have my code included in that, I must admit SMF's a pretty awesome looking tool. I've also been considering someday working with your ShellTriStateTreeView, another awesome program.

[Ascend4nt 118]

Updated UDF to support AutoIT v3.3, or UNICODE v3.2.12.1, see 1st post for new code

[KaFu 184]

Awesome function set, just needed a bump ...

[WeMartiansAreFriendly 1]

Wow... the speed stats are impressive.. at least for the first run

_WinAPI_FileFind Stats:
Total File count:2072, Total Folder count:52, Time elapsed:823.423088688646 ms
FileFindFile Stats:
Total File count:2072, Total Folder count:52, Time elapsed:2259.5382932747 ms

Second run and so on; I'm getting varied results. Most of the time FileFindFile() is faster your function.

_WinAPI_FileFind Stats:
Total File count:2072, Total Folder count:52, Time elapsed:1103.81850207219 ms
FileFindFile Stats:
Total File count:2072, Total Folder count:52, Time elapsed:671.125240777808 ms

a little better...

_WinAPI_FileFind Stats:
Total File count:2072, Total Folder count:52, Time elapsed:867.172224402822 ms
FileFindFile Stats:
Total File count:2072, Total Folder count:52, Time elapsed:688.528849336997 ms

[KaFu 184]

Second run and so on; I'm getting varied results. Most of the time FileFindFile() is faster your function.

That depends on what you expect to be the return , this one not only returns file location info, but at the same time file-attributes, size and times...

[Ascend4nt 118]

Wow... the speed stats are impressive.. at least for the first run

...

Second run and so on; I'm getting varied results. Most of the time FileFindFile() is faster your function.

...

Kastout, I think I remarked that for getting the attributes and all, _WinAPI_FileFind will always be faster than FileFind.. functions. As for getting just pure filename info, your best bet is the built in FileFind.. functions.

Also, remember, when you are timing how long it takes to read files on a hard drive, the first search will always be the longest, and all subsequent calls will be much faster. That's due to how Windows will buffer the information (though how long the results stay in memory I couldn't say).

The best bet for a clear performance comparison is to reboot Windows between compares. (And don't run them one after the other, but one version on the first clean boot, the other on the 2nd boot)

Also make sure you don't have any other processes actively eating up processor time or accessing the hard drive excessively..

[Ascend4nt 118]

Awesome function set, just needed a bump ...

Hey, thanks for promoting my UDF You even added it to your sig! Wow, and who gave this UDF 5 stars? Nothing I ever did got stars!! haha.. i feel special now

By the way, I've rewritten this UDF so that it can indeed grab the FileTime as a 64-bit number (has to do with structure-alignment), for a little less code and ease of use (and the ability to do some neat manipulations).

Then I went further and made it possible to format the time string in a crapload of ways, to manipulate the FileTime itself (adding/subtracting minutes, hours, days, and so on), and do multiple conversions.

But I digress... all that stuff I'd rather not post here, because this as it stands does just enough and the programmer can choose to modify it at their own leisure.

Anyway, thanks again. Seeya around the forums!

[rajeshontheweb 0]

is the udf missing?

[Scriptonize 1]

is the udf missing?

Yes, the member has left the building and he decided to take his code with him. >_<

This is what he has written in his profile about removing the code:

My apologies to the AutoIT community for removing my posted code. This was done because I knew I would be banned, and I'd rather not have the inability to access, update, and respond to anything related to MY hard work. I hope to move my code over to Google sites, but for now I'm just posting on my blog about the potential future.

For those that want to know about the banning, and my response to the person-responsible's incorrect assertions in this thread, you could visit this blog post. (He specifically said he did not want to discuss things further - which often means 'you'll be banned if you continue', so this is my only recourse)

[Ascend4nt 118]

Text and Link to code is now added. Sorry about any inconveniences

[Ascend4nt 118]

After having this sitting on my PC for a while, I decided to upload the new version. It has the same functioning as it did before, but the FileTime's are now individual array items, and additionally the _WinTimeFunctions module is needed.

UPDATES:

- 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.

[Ascend4nt 118]

This UDF has been updated! Besides getting rid of the '_WinAPI_' prefix, I've worked on increasing performance with this release, as well as providing Reparse Point information. I'm dedicating this update to KaFu, maker of the fine SMF (Search My Files) program, which includes an older version of this UDF.

Updates:

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.

[KaFu 184]

I'll definitly incorporate this one into the upcoming v1.6 release of SMF , thanks a lot m8, your work is really much appreciated!

[Ascend4nt 118]

Ahh! I just looked at your 1.5 source again and realized there will be more script-breaking changes then I listed, since you used an older version which still used 32-bit values instead of 64-bit ones (changed in last year's release). The array will now be indexed/accessed differently for you, so it'll be a little more work to get the indexes correct. Sorry about that, mate!