Jump to content
Sign in to follow this  
Ascend4nt

_FileFindEx - Get More from File/Folder Searches

Recommended Posts

_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 by Ascend4nt

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

@ascendant

Great and useful job ! :P

Five stars from me :unsure:

Cheers, FireFox.


 

OS : Win XP SP2 (32 bits) / Win 7 SP1 (64 bits) / Win 8 (64 bits) | Autoit version: latest stable / beta.
Hardware : Intel(R) Core(TM) i5-2400 CPU @ 3.10Ghz / 8 GiB RAM DDR3.

My UDFs : Skype UDF | TrayIconEx UDF | GUI Panel UDF | Excel XML UDF | Is_Pressed_UDF

My Projects : YouTube Multi-downloader | FTP Easy-UP | Lock'n | WinKill | AVICapture | Skype TM | Tap Maker | ShellNew | Scriptner | Const Replacer | FT_Pocket | Chrome theme maker

My Examples : Capture toolIP Camera | Crosshair | Draw Captured Region | Picture Screensaver | Jscreenfix | Drivetemp | Picture viewer

My Snippets : Basic TCP | Systray_GetIconIndex | Intercept End task | Winpcap various | Advanced HotKeySet | Transparent Edit control

 

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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.


Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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!


Share this post


Link to post
Share on other sites

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)


If you learn from It, it's not a mistake

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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.


Share this post


Link to post
Share on other sites

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.


Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

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!


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • By dinotom
      Can files be read from the web or the cloud?
      I am trying to read this file but get the file open error.
      #include <FileConstants.au3> #include <MsgBoxConstants.au3> ;Assign the file path to a variable Local $sFilePath = "C:\Automation\test.txt" Local $sFilePathAzure ="https://batlgroupimages.blob.core.windows.net/files/test.txt" Local $nLineNumberToLookFor = 0 ;Open the file test.txt in append mode. ;If the folder C:\Automation does not exist, it will be created. Local $hFileOpen = FileOpen($sFilePathAzure, $FO_APPEND + $FO_CREATEPATH) ;Display a message box in case of any errors. If $hFileOpen = -1 Then MsgBox($MB_SYSTEMMODAL, "", "An error occurred while opening the file.") EndIf ;Set the file position to beginning for reading the data from the beginning of the file. FileSetPos($hFileOpen, 0, $FILE_BEGIN) ;Read the data from the file using the handle returned by FileOpen ;Local $sFileRead = FileRead($hFileOpen) ;Read the 2nd line of data from the file using the handle returned by FileOpen Local $sFileReadLine = FileReadLine ($hFileOpen,2) ;Close the handle returned by FileOpen. FileClose($hFileOpen)  
    • By jresine
      Hello, is it possible to know via a script or command, to have the percentage of disk usage of a process? thank you in advance.
      ps: see image

    • By Pike
      Hey Everyone, I haven't been here in a while and recently picked up my old project. Still an FNG!
      To the point: I want to be able to push the button and either play an mp3, open a file, or open an exe program (all with the same button). The problem is that I don't know how to code for that at "case 1"
              Case 1                                                                                                                                             
                  Local $sRead = IniRead("config.ini", "Config", "One", "Default")                                
                  SoundPlay($sRead, @HotKeyPressed)                                                                     <-------------------------------
                  Run($sRead, @HotKeyPressed)                                                                                 <------------------------------- This 'Run' doesn't work even by itself!
      See code below for layout. If you need more information I will attach more code or answer any questions. Any help is greatly appreciated.
       
      Much Respect,
      Pike
       
      Func _HandleButton() $iClickCount += 1 $iTimer = TimerInit() AdlibRegister("CheckButtonPress", $CheckTime) EndFunc Func CheckButtonPress() If TimerDiff($iTimer) < $CheckTime Or $iTimer = 0 Then Return Switch $iClickCount Case 1 Local $sRead = IniRead("config.ini", "Config", "One", "Default") SoundPlay($sRead, @HotKeyPressed) Run($sRead, @HotKeyPressed) Case 2 MsgBox(0, "INFORMATION:", "Choose the file you want designated to this button") Local $sFileOpenDialog = FileOpenDialog(0, @ScriptDir & "\", "All (*.*)", $FD_FILEMUSTEXIST + $FD_MULTISELECT) If @error Then MsgBox($MB_SYSTEMMODAL, "", "No file(s) were selected.") EndIf Local $sFileName = InputBox("INFORMATION:", "Please Name Your File?" & @CRLF _ & @CRLF _ & "6 Characters or Less", "") IniWrite(@ScriptDir & "\config.ini", "Config", "One", $sFileOpenDialog) IniWrite(@ScriptDir & "\config.ini", "Config", "NameOne", $sFileName) EndSwitch $iClickCount = 0 AdlibUnRegister() EndFunc  

    • By nacerbaaziz
      hi dears, i have a question please
      am now working for an audio player for the blind users
      and i added an option to open a file from the right click context menu.
      but here there is a small problem, i hope that you can help me to find a solution for it.
      the problem is as follow :
      when i added the problem into the context menu it work with successfuly if the user select just one file.
      but if the user selected more then one file, here the problem
      a multiple sections of the program will open.
      my question is :
      how i can detect the multiple selection from the context menu?
      i know that it so  hard, but i know also that you are harder than it
      for that dears please try to give me an solution for that problem.
      thanks in advance
    • By vin1
      i have a script that selects  a text file and deletes a line (text input required) in the text file selected
      i have to make it remove all lines found on a file i name, toRemoveLines.txt
      it has to remove lines from all text files found in a folder
      this is the script that has to be modified
      where it says "select file" it has to be "select folder"
      where it says "line text input" it has to be all lines from a text file
      #Include <File.au3> Global $success = False $file_name = FileOpenDialog("Select file", @ScriptDir, "All files (*.*)", 1+4) $line_text_input = InputBox("Line's text", "Line must contain following text:", "line contains this text") $file_count_lines = _FileCountLines($file_name) for $i = 0 to $file_count_lines $Lines_text_output = FileReadLine($file_name, $i) if StringInStr($Lines_text_output, $line_text_input) then _FileWriteToLine($file_name, $i, "", 1) $success = True ExitLoop EndIf Next if $success = True Then MsgBox(0, "Success", "Line has been deleted") Else MsgBox(0, "Failure", "Line wasn't found") EndIf  
×
×
  • Create New...