SwiftSearch requires Admin privileges and only searches one NTFS volume at a time.
However, it is VERY FAST!
You can use regular expressions or use a search pattern like t*.xl?? to find Excel files beginning with t or T. On my 250GB nearly full C: volume it did this search in about 1 second (after reading the NTFS file table on the first search, which took about 5 seconds)!
Not only is it fast, but it actually finds the files I am looking for (even if it is a hidden or system file) unlike the next-to-useless Win 7 search engine! Finally you can disable the resource hungry and delay-causing Windows Search Service and no need for an enormous index file either.
SwiftSearch is a standalone executable and therefore is a portable application - it ran fine under a vanilla Windows 7 PE environment too. This means it could be very useful for booting a system to WinPE from a USB drive and then quickly using SwiftSearch to find and copy an important file (or all .doc files?) onto your USB drive. Unfortunately you can only select and copy one file at a time in the search results (no Ctrl+A function) but at least right-click works as expected on individual files. Maybe this will be fixed soon?
#1
Posted 05 September 2013 - 05:44 PM
- erwan.l likes this
#2
Posted 05 September 2013 - 06:10 PM
Hmmm.
(at the idea of "lightweight program"), comparatively it's "bloated".
Description
SwiftSearch is a lightweight program whose purpose is to help you quickly find the files you need on your Windows machine without ever requiring you to index your drives.
JFYI, should be "as fast as":
http://reboot.pro/to...lick-like-tool/
NTFS_search 130 Kb
NDFF (command line) 156 Kb
Additionally (again JFYI):
http://www.msfn.org/...ster-using-mft/
Wonko
#3
Posted 06 September 2013 - 11:26 PM
Hi, I'm the author of SwiftSearch. I'm glad you liked the program.
I just wanted to respond to your feedback:
Unfortunately you can only select and copy one file at a time in the search results (no Ctrl+A function)
The reason for this is that the selected files may be in different folders.
What do expect the program should do if you selected a file and its parent folder?
You can't copy the files (that doesn't make sense), and Windows doesn't have any right-click menu to show you (they're in different folders), so selecting multiple files wouldn't be very useful.
If you think it's still useful I would be happy to add it -- just let me know why it would be so.
Edited by wfunction, 06 September 2013 - 11:27 PM.
#4
Posted 07 September 2013 - 07:20 AM
Hi
Yes, it would absolutely be useful. Because SwiftSearch will run under PE and does not need to be installed, it would be an ideal 'rescue' tool to copy files off of a system that will no longer boot but contains important files. For example, copy off all my docx, xls, jpg files before I reformatted the drive and re-installed.
Many times I have been asked to 'rescue' files from a friends PC that won't boot, but they don't know where their important files are and I can only boot to WinPE from a USB drive or CD/DVD and so there are none of the usual shortcuts or Start menu items.
The Windows search function in Explorer allows you to select the results and cut and paste them to a destination folder - any filename clashes are handled by changing the filename to xxx(1).ext. You can also use the Send To in the search results pane which sends all files to the root of the target drive. This would be good to have in SwiftSwearch.
I would strongly suggest that it would be very nice to select multiple files from SwiftSearch and then be able to copy them all to a target folder and preserve the directories, so if that if S:\myolder is selected as the target folder, then the highlighted items, e.g.
C:\xxxx\yyyy\zzz.docx would be copied to S:\myfolder\xxxx\yyyy\zzz.docx (and s:myfolder created if it did not already exist)
C:\xxxx\aaa.docx would be copied to S:\myfolder\xxxx\aaa.docx
etc.
It would also be nice to be able to copy all contents from one single folder, e.g. if C:\xxxxx\found.docx was highlighted and right-clicked, you get the option to copy the whole folder..
C:\xxxx\*.* would be copied to S:\myfolder\xxxx (and all sub-folders)
With this functionality, it would soon be adopted by many people in their WinPE builds as a 'search and rescue' tool and would greatly expand it's use (and probably get put into the next release of Hiren's Boot CD and the UBCD too!).
It would also be VERY useful if it could search non-NTFS drives too (in the normal slow way, of course).
Did you see my suggestion of a Refresh or 're-Index' button or automatically detecting changes in the $MFT/$bitmap and auto-refreshing if a change was detected in the volume files (for when you copy a file to another folder on the same drive and then click search to try to find it)?
cheers
Steve
#5
Posted 07 September 2013 - 09:08 AM
Hi wfunction,
Thanks for your tool. It's very fast. The GUI version works fine on my XP SP3 but the console version is displaying the following error message :
SwiftSearchConsole.exe is not a valid win32 application.
#6
Posted 07 September 2013 - 11:00 AM
Hi wfunction,
Thanks for your tool. It's very fast. The GUI version works fine on my XP SP3 but the console version is displaying the following error message :
Hi Vortex,
Thanks for letting me know. It's the Visual Studio 2012 compiler's fault, it doesn't like Windows XP.
It should be fixed now, try downloading it again.
#7
Posted 07 September 2013 - 11:11 AM
Hi Steve,
Hi
Yes, it would absolutely be useful. Because SwiftSearch will run under PE and does not need to be installed, it would be an ideal 'rescue' tool to copy files off of a system that will no longer boot but contains important files. For example, copy off all my docx, xls, jpg files before I reformatted the drive and re-installed.
Many times I have been asked to 'rescue' files from a friends PC that won't boot, but they don't know where their important files are and I can only boot to WinPE from a USB drive or CD/DVD and so there are none of the usual shortcuts or Start menu items.
The Windows search function in Explorer allows you to select the results and cut and paste them to a destination folder - any filename clashes are handled by changing the filename to xxx(1).ext. You can also use the Send To in the search results pane which sends all files to the root of the target drive. This would be good to have in SwiftSwearch.
I would strongly suggest that it would be very nice to select multiple files from SwiftSearch and then be able to copy them all to a target folder and preserve the directories, so if that if S:\myolder is selected as the target folder, then the highlighted items, e.g.
C:\xxxx\yyyy\zzz.docx would be copied to S:\myfolder\xxxx\yyyy\zzz.docx (and s:myfolder created if it did not already exist)
C:\xxxx\aaa.docx would be copied to S:\myfolder\xxxx\aaa.docx
etc.
It would also be nice to be able to copy all contents from one single folder, e.g. if C:\xxxxx\found.docx was highlighted and right-clicked, you get the option to copy the whole folder..
C:\xxxx\*.* would be copied to S:\myfolder\xxxx (and all sub-folders)
I would love to make this work... but I don't understand though.
What should happen if you highlight all of the following:
C:\Users\YourName\
C:\Users\YourName\Desktop\
C:\Users\YourName\Desktop\Test.pdf
and try to right-click and select Copy, then Paste it into D:\Bar?
Should C:\Users\YourName\Desktop\Test.pdf get copied three times?
Exactly which directory should it get copied to?
With this functionality, it would soon be adopted by many people in their WinPE builds as a 'search and rescue' tool and would greatly expand it's use (and probably get put into the next release of Hiren's Boot CD and the UBCD too!).
If I can make it do something sensible I'll definitely add it.
Right now I'm not sure what the proper behavior would be (see above).
It would also be VERY useful if it could search non-NTFS drives too (in the normal slow way, of course).
I like the idea but this would probably require a ton of effort to implement correctly, since the program wasn't meant to do this... so it probably won't be added soon. Maybe I'll add it in a year or so, when I have some more time.
Did you see my suggestion of a Refresh or 're-Index' button or automatically detecting changes in the $MFT/$bitmap and auto-refreshing if a change was detected in the volume files (for when you copy a file to another folder on the same drive and then click search to try to find it)?
No I haven't seen it, but the feature is already there (sorry I haven't mentioned it anywhere):
If you press F5 it should invalidate the index for the selected drive and immediately index it again.
Edited by wfunction, 07 September 2013 - 11:15 AM.
#8
Posted 07 September 2013 - 01:38 PM
What should happen if you highlight all of the following:
C:\Users\YourName\
C:\Users\YourName\Desktop\
C:\Users\YourName\Desktop\Test.pdf
and try to right-click and select Copy, then Paste it into D:\Bar?
Prefer top level C:\Users\YourName\
Ignore C:\Users\YourName\Desktop\ and C:\Users\YourName\Desktop\Test.pdf
Copy C:\Users\YourName\ only.
Result D:\Bar\YourName\
#9
Posted 07 September 2013 - 05:50 PM
Hi wfunction,
Thanks, I downloaded the new release but it displays another message now on XP SP3 :
SwiftSearchConsole.exe c:\*.doc
Error 0xC0000033 opening "\\.\c:\*.doc": Object Name
Also, could you add a small documentation demonstrating how to use the console version?
SwiftSearchConsole.exe -h or /? should display the usage.
#10
Posted 08 September 2013 - 01:45 AM
Prefer top level C:\Users\YourName\
Ignore C:\Users\YourName\Desktop\ and C:\Users\YourName\Desktop\Test.pdf
Copy C:\Users\YourName\ only.
Result D:\Bar\YourName\
Hmm... that might be confusing but I guess I could implement it sometime.
If I do, though, I'll have to make my own context menu -- Windows doesn't have any context menu that supports multiple files in different folders.
(So, there won't be a "Send To" or anything like that. Just "Copy".)
#11
Posted 08 September 2013 - 01:47 AM
Hi wfunction,
Thanks, I downloaded the new release but it displays another message now on XP SP3 :
Also, could you add a small documentation demonstrating how to use the console version?
SwiftSearchConsole.exe -h or /? should display the usage.
Ah yeah sorry, I hadn't gotten around to adding support for /? unfortunately.
The console version was meant to be called like this:
SwiftSearchConsole.exe C: D:
and subsequently pipe'd into grep or something. It wasn't meant to be used without further processing (though I might add that later).
#12
Posted 08 September 2013 - 07:05 AM
Hi wfunction,
Thanks for the info. This one works fine :
SwiftSearchConsole.exe C: | findstr "test.txt"
#13
Posted 08 September 2013 - 03:14 PM
The most common use in a 'rescue' situation under WinPE would be to find say all *.docx files in a system.
This would result in a list of files.
Now the next thing that would be wanted is to select and copy those files to some other media (e.g. USB drive), so a 'copy files' button would copy all the files to a USb drive.
e.g. results pane has:
C:\docs\fred.docx
C:\docs\user1\simon.docx
C:\usres\ss\g.docx
in results pane, select some or all files using ctrl+left-click maybe or ctrl+A - click 'copy files' button/menu item - get prompt to choose destination folder - navigate to a folder on USB drive G:\backup - click 'Copy' (Cancel button also available).
all above files (or selected/highlighted files) would be copied to
G:\backup\docs\fred.docx
G:\backup\docs\user1\simon.docx
G:\backup\usres\ss\g.docx
and voila, all document files would be backed up! Any folders selected would be ignored.
You could also have a 'Copy folders' button which would copy all files in selected folders to a destination folder (any files that were selected would simply be ignored)
e.g Search for Yourname - get results
C:\Users\YourName\
C:\Users\YourName\Desktop\
C:\Users\YourName\Desktop\Test.pdf
User selects all items (ctrl+A) and clicks 'Copy Folders' and select destination folder - e.g. G:\backup - contents of each folder are copied over, e.g.
G:\backup\Users\YourName\*.*
G:backup\Users\YourName\Desktop\*.*
It would be even better if there was the option for 'copy single folder+all subfolders' but only one source folder would be allowed to be selected from the results pane by the user.
Maybe you could simply rely on Xcopy to do the actual copy work (I think Xcopy is included in all PE's ?).
#14
Posted 08 September 2013 - 06:33 PM
The most common use in a 'rescue' situation under WinPE would be to find say all *.docx files in a system.
This would result in a list of files.
Now the next thing that would be wanted is to select and copy those files to some other media (e.g. USB drive), so a 'copy files' button would copy all the files to a USb drive.
e.g. results pane has:
C:\docs\fred.docx
C:\docs\user1\simon.docx
C:\usres\ss\g.docx
in results pane, select some or all files using ctrl+left-click maybe or ctrl+A - click 'copy files' button/menu item - get prompt to choose destination folder - navigate to a folder on USB drive G:\backup - click 'Copy' (Cancel button also available).
all above files (or selected/highlighted files) would be copied to
G:\backup\docs\fred.docx
G:\backup\docs\user1\simon.docx
G:\backup\usres\ss\g.docx
and voila, all document files would be backed up! Any folders selected would be ignored.
You could also have a 'Copy folders' button which would copy all files in selected folders to a destination folder (any files that were selected would simply be ignored)
e.g Search for Yourname - get results
C:\Users\YourName\
C:\Users\YourName\Desktop\
C:\Users\YourName\Desktop\Test.pdf
User selects all items (ctrl+A) and clicks 'Copy Folders' and select destination folder - e.g. G:\backup - contents of each folder are copied over, e.g.
G:\backup\Users\YourName\*.*
G:backup\Users\YourName\Desktop\*.*
It would be even better if there was the option for 'copy single folder+all subfolders' but only one source folder would be allowed to be selected from the results pane by the user.
Maybe you could simply rely on Xcopy to do the actual copy work (I think Xcopy is included in all PE's ?).
If I implement this, I would just use SHFileOperation(), no need for Xcopy.
#15
Posted 08 September 2013 - 06:38 PM
@wfunction:
Your tool is great! Test times surprised me. I'm going to add to Win7PE.
But maybe a bit later. Currently I got a hang in one test. I'm going to explore and report to you.
@steve: Many thanks for the hint!
Peter
#16
Posted 08 September 2013 - 07:32 PM
@wfunction:
Your tool is great! Test times surprised me. I'm going to add to Win7PE.
But maybe a bit later. Currently I got a hang in one test. I'm going to explore and report to you.
Thanks!
#17
Posted 08 September 2013 - 07:37 PM
It's also worth mentioning:
If you hold down SHIFT when pressing Search, the tool will display all NTFS attributes, not just $DATA.
(Well, all of them except 8.3 file names.)
Edited by wfunction, 08 September 2013 - 07:42 PM.
#18
Posted 09 September 2013 - 02:39 AM
Hmmm.
(at the idea of "lightweight program"), comparatively it's "bloated".
Yeah, I agree it looks that way.
However... that 850-KB program actually contains both the 32-bit (350 KB) and 64-bit (500 KB) versions.
Of the 850 KB total, 410 KB are just for supporting regular expressions (from Boost), and 40 KB are for the icon.
So, if I removed regular expression support as well as the icon, the rest is only around 175 KB for the 32-bit executable (225 KB for 64-bit), which is honestly not that bloated.
Edited by wfunction, 09 September 2013 - 02:40 AM.
#19
Posted 09 September 2013 - 09:40 AM
Yeah, I agree it looks that way.
However... that 850-KB program actually contains both the 32-bit (350 KB) and 64-bit (500 KB) versions.
Of the 850 KB total, 410 KB are just for supporting regular expressions (from Boost), and 40 KB are for the icon.
So, if I removed regular expression support as well as the icon, the rest is only around 175 KB for the 32-bit executable (225 KB for 64-bit), which is honestly not that bloated.
Maybe simply making the two editions separated (32 and 64) would be enough
The issue with "regular" expressions is that they are IMHO irregular , in the sense that the average "regular" user will have not even a hint on how they actually work, and even rather "advanced" users usually have issues with them.
More generally, since we are into (very fast ) searching and finding, there is not much sense in spending - say - 5 minutes in crafting a well targeted regular expression as it would be faster to search for a half-@§§ed expression and choose the results, the only use would probably be or use in batches.
If someone would also be so kind as to run on the SAME 64 bit system both the 32 bit and the 64 bit version (once they will be - hopefully - separated) a few "same" searches I would be very interested in the difference in speed between them.
The tool is however very good and fast
The console version is seemingly greatly "penalized" by the piping into FIND or FINDSTR , when and if you will have time to add an internal filtering engine, I am sure it will become a "can't do without" tool for people using batches .
If you could add to it (again when and if you have time) options similar to the ones in the mentioned ndff:
NTFS Direct File Find 0.9.6
Syntax: ndff [-<option>...] <filename> [-<option>...]
Options:
-? Help page (also -h)
-about About the NDFF, license & legal info
-deferred List results after the search is complete
-range <begin> [<end>] Scan ID range lower and upper bounds (default: 0 -1)
-case Case sensitive search
-d <drive> Specify drive letter (in form of 'd:') (default: current drive)
-regex Use regular expressions
-nocache Disable directory cache
-JP Do not resolve junction points
Output redirection:
-outfile <filename> Save output to Unicode file
-outCON Suppress console output
Column displaying options:
-si Show file MFT ID
-ssize Show file size
-salloc Show allocated size
-snamespace Show namespace of the filename
-sd Show drive letter
-sP Do not show file path
-silent Only list found files, do not show summary
Filename namespace selection: (only one allowed)
-nall Look all filename namespaces
-nwin32 Look Win32 namespace (default)
-ndos Look DOS namespace
-nposix Look POSIX namespace
Result filtering options:
-fDIRS Do not list directories
-fFILES Do not list regular files
-fsize <min> [<max>] List only files with file size in range (default: 0 -1)
-falloc <min> [<max>] List only files with allocated size in range (default: 0 -1)
-funused Include unused files in result
-fUSED Do not list used files
-fsystem Show special NTFS files
Following characters are accepted as option switch: -/
I am pretty sure we will have a winner .
OT (but not much) how does the app treat junction points and hard links? (as I am afraid on modern NT systems they are having more and more relevance)
Also, for some uses it may be useful "limiting" the search field (i.e. have in the dropdown on the left, besides the "main" drive letters, the possibility to choose a directory or path).
Wonko
#20
Posted 09 September 2013 - 04:19 PM
To the APP author: Great app, works a treat on Windows 7. Very fast.I have an issue with it on Windows 2003 on a very large partition. Sorry I know this is not a support forum for your app but I am loath to sign up for yet another site just to post about a freeware app. Please disregard if you wish not to address it here. Thanks for the app.
I tried it on our server, Windows 2003 32 bit with a 4TB data drive, it gets to 39% finished on the disk scan for the first query and freezes and eventually just pops off the screen without any error messages immediately. After a few minutes an error popped up and said that SwiftSearch caused an error and needed to close. Server is Windows 2003 server standard edition with 4Gb ram on a VMWare ESXi . I CAN search on the local C: OS drive which is only 32 GB in size.
Event log details:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 9/9/2013
Time: 11:05:05 AM
User: N/A
Computer: RQXSM003
Description:
Faulting application SwiftSearch.exe, version 0.0.0.0, faulting module SwiftSearch.exe, version 0.0.0.0, fault address 0x0000ebe3.
For more information, see Help and Support Center at http://go.microsoft....link/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 53 77 69 ure Swi
0018: 66 74 53 65 61 72 63 68 ftSearch
0020: 2e 65 78 65 20 30 2e 30 .exe 0.0
0028: 2e 30 2e 30 20 69 6e 20 .0.0 in
0030: 53 77 69 66 74 53 65 61 SwiftSea
0038: 72 63 68 2e 65 78 65 20 rch.exe
0040: 30 2e 30 2e 30 2e 30 20 0.0.0.0
0048: 61 74 20 6f 66 66 73 65 at offse
0050: 74 20 30 30 30 30 65 62 t 0000eb
0058: 65 33 e3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#21
Posted 09 September 2013 - 07:13 PM
Maybe simply making the two editions separated (32 and 64) would be enough
Maybe simply making the two editions separated (32 and 64) would be enough
The issue with "regular" expressions is that they are IMHO irregular , in the sense that the average "regular" user will have not even a hint on how they actually work, and even rather "advanced" users usually have issues with them.
More generally, since we are into (very fast ) searching and finding, there is not much sense in spending - say - 5 minutes in crafting a well targeted regular expression as it would be faster to search for a half-@§§ed expression and choose the results, the only use would probably be or use in batches.
The average user can just use wildcards, that's why they're the default.
Regular expressions can be really useful... sorry if you don't find them useful but I find them useful myself, so I probably won't remove them.
If someone would also be so kind as to run on the SAME 64 bit system both the 32 bit and the 64 bit version (once they will be - hopefully - separated) a few "same" searches I would be very interested in the difference in speed between them.
The tool is however very good and fast
The console version is seemingly greatly "penalized" by the piping into FIND or FINDSTR , when and if you will have time to add an internal filtering engine, I am sure it will become a "can't do without" tool for people using batches .
SwiftSearchConsole C: -A:-2h
If you could add to it (again when and if you have time) options similar to the ones in the mentioned ndff
I am pretty sure we will have a winner .
I hadn't heard of NDFF, thanks for the reference!
I'll consider it, but honestly my hope has been to provide a good GUI experience -- not to make a command-line tool.
The reason I only made a command-line version at all was to help an admin dump a "snapshot" of the system -- it wasn't meant to be a general-purpose searching tool unfortunately.
OT (but not much) how does the app treat junction points and hard links? (as I am afraid on modern NT systems they are having more and more relevance)
Also, for some uses it may be useful "limiting" the search field (i.e. have in the dropdown on the left, besides the "main" drive letters, the possibility to choose a directory or path).
I like the idea, but at the same time it would mislead the user into thinking the search might be "faster" that way (since they're "only" searching a small directory), when in fact it won't be.
Maybe I'll add it but it's not terribly important so it'll be a while if I do.
Edited by wfunction, 09 September 2013 - 07:23 PM.
#22
Posted 09 September 2013 - 07:18 PM
To the APP author: Great app, works a treat on Windows 7. Very fast.I have an issue with it on Windows 2003 on a very large partition. Sorry I know this is not a support forum for your app but I am loath to sign up for yet another site just to post about a freeware app. Please disregard if you wish not to address it here. Thanks for the app.
I tried it on our server, Windows 2003 32 bit with a 4TB data drive, it gets to 39% finished on the disk scan for the first query and freezes and eventually just pops off the screen without any error messages immediately. After a few minutes an error popped up and said that SwiftSearch caused an error and needed to close. Server is Windows 2003 server standard edition with 4Gb ram on a VMWare ESXi . I CAN search on the local C: OS drive which is only 32 GB in size.
Two possibilities:
1. I think somewhere in the tool I assumed the partition won't be bigger than a few terabytes. I think I assumed 16 TB instead of 4 TB, but I'm not sure... I'll have to remember why this matters and double-check.
2. My best guess is that you're running out of memory.
There's probably not much I can about running out of memory (though I do have some ideas of how I can try to reduce the memory usage a bit).
Can you try running an older version (e.g. version 1.3)?
If it works, then I might be able to reduce the newer one's memory usage, since I think one of my changes increased it a bit.
If it doesn't, then I probably can't -- your drive is simply too big for your computer to fit the entire file table in memory at once. If that's the case, you should switch to a 64-bit operating system and get more RAM -- or if you don't have more RAM, at least create a page file on the disk. A 32-bit system just can't handle too much data.
Also, how big is your file table on that partition?
If you type
FSUtil FSInfo NTFSInfo D:
it will tell you the "Mft Valid Data Length".
Edited by wfunction, 09 September 2013 - 07:22 PM.
#23
Posted 09 September 2013 - 07:41 PM
I've been using a similar 'tool' since late 2009 which I find is very good.
I'ts called Everything more about it here:
http://www.voidtools.com/faq.php
also
http://en.wikipedia....hing_(software)
#24
Posted 09 September 2013 - 08:33 PM
I've been using a similar 'tool' since late 2009 which I find is very good.
I'ts called Everything more about it here:
http://www.voidtools.com/faq.php
also
Yes I learned about it recently.
I think when I tried it, it was slower than SwiftSearch?
I only tried it once, so not sure.
#25
Posted 09 September 2013 - 09:04 PM
No disrespect, keep up the good work .... your program is also mentioned on the wiki page, as of yet I have not had time to try it.
I only mentioned it as a matter of fact and to make the community aware of other such programs.
For me it's been a ' Where did I put my glasses program'
I wish you every success.
Also tagged with one or more of these keywords: utility, search, file, find
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users