Jump to content











Photo
- - - - -

Windows File Search Utility that is FAST!

utility search file find

  • Please log in to reply
36 replies to this topic

#1 steve6375

steve6375

    Platinum Member

  • Developer
  • 6629 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 05 September 2013 - 05:44 PM

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?


  • erwan.l likes this

#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 September 2013 - 06:10 PM

Hmmm. :dubbio:

(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/

 

 

:cheers:

Wonko



#3 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 steve6375

steve6375

    Platinum Member

  • Developer
  • 6629 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

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 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 232 posts

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 cdob

cdob

    Gold Member

  • Expert
  • 1344 posts

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 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 232 posts

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 232 posts

Posted 08 September 2013 - 07:05 AM

Hi wfunction,

 

Thanks for the info. This one works fine :

SwiftSearchConsole.exe C: | findstr "test.txt"


#13 steve6375

steve6375

    Platinum Member

  • Developer
  • 6629 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12688 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

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 :cheers:



#16 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

Posted 08 September 2013 - 07:37 PM

It's also worth mentioning:

 
If you hold down CONTROL when pressing Search, the tool will display deleted files (in red).
If you right-click them, you will see the file number.
Combined with DiskBuddy's ability to read the MFT, that should be enough to tell you where a file is located on the disk.
(It wasn't meant to be powerful -- it's only meant to show you if a file still exists in the file table or not, so you can use a different tool for recovery.)

 

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

Posted 09 September 2013 - 02:39 AM

Hmmm. :dubbio:

(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 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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 :unsure:

 

The issue with "regular" expressions is that they are IMHO irregular :w00t:, 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 :thumbsup:) 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. :dubbio:

 

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 :thumbsup:

 

The console version is seemingly greatly "penalized" by the piping into FIND or FINDSTR :unsure:, 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 :worship:.

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 :1st: .

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

 

 

:cheers:

Wonko



#20 Rootman

Rootman

    Frequent Member

  • Advanced user
  • 243 posts
  • Location:USA

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

Posted 09 September 2013 - 07:13 PM

Maybe simply making the two editions separated (32 and 64) would be enough :unsure:

 
What's the benefit of separating them though?
 
If you find it that useful to have separate 32-bit and 64-bit versions then you can just use a tool like Resource Hacker to extract the 64-bit version from the binary yourself.
I've packed them together but it takes like 1 minute to separate them!
 
 

Maybe simply making the two editions separated (32 and 64) would be enough  :unsure:

 

The issue with "regular" expressions is that they are IMHO irregular  :w00t:, 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  :thumbsup:) 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.  :dubbio:

 

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.

 
I don't think the 64-bit version will be faster. In fact, it might even be slower.
I've created a 64-bit version because of:
- Expanded memory, not higher speed. If you have a lot of partitions (or a huge partition) you can go over 2-3 GB of memory usage.
- Icon handlers sometimes don't have 32-bit support on 64-bit systems, so the user might see bizarre icons if he tries to use a 32-bit version on 64-bit Windows.
 
In fact, the post below yours seems to show what happens when you run out of memory!
 
 

The tool is however very good and fast  :thumbsup:

Thanks!
 
 

The console version is seemingly greatly "penalized" by the piping into FIND or FINDSTR  :unsure:, 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  :worship:.

 
Hmm... when I try it on my own system FINDSTR doesn't seem to add any noticeable penalty.
 
That said, the console version does have filtering for dates -- just not for names. I just haven't mentioned it anywhere.
You can say
SwiftSearchConsole C: -A:-2h
to find all files that were Accessed within the last 2 hours.
 
 

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  :1st: .

 

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)

 
"Correctly", I think.
 
If you have N hard links to a file, each of them will have its file size divided by N (I think I even made sure to prevent round-off errors?), so the sizes will add up correctly and you should be able to search using any hard link's name.
 
There's nothing particularly significant about junctions. I don't try to go "into" them so they should just show up as empty folders.
 
So you can use SwiftSearch as a disk-space analysis tool too, not just a searching program! Just sort by the Size on Disk.
 
 

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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 saddlejib

saddlejib

    Frequent Member

  • Advanced user
  • 270 posts
  •  
    United Kingdom

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 wfunction

wfunction

    Newbie

  • Members
  • 20 posts

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

 

http://en.wikipedia....hing_(software)

 

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 saddlejib

saddlejib

    Frequent Member

  • Advanced user
  • 270 posts
  •  
    United Kingdom

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

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users