Is there UDF for Everything search tool?

[littleclown]

Hello.

For thous who don't know what is "Everything" here is information: http://www.voidtools.com/

In two words - Everything is tool for searching local drives for files and folders (by name) extremely fast. One normal search costs something like 1-2 seconds.

I need to integrate this tool in my autoit script. Now I try to use combination of Everything and pstools to make an network search engine (start everything on a remote server with pstools), but the main difficult is that I just can't force Everything to create new DB somewhere and quit... If someone have UDF for this tool I will be happy to test it.

Thanks in advanced.

[contrex]

Hello.

For thous who don't know what is "Everything" here is information: http://www.voidtools.com/

In two words - Everything is tool for searching local drives for files and folders (by name) extremely fast. One normal search costs something like 1-2 seconds.

I need to integrate this tool in my autoit script. Now I try to use combination of Everything and pstools to make an network search engine (start everything on a remote server with pstools), but the main difficult is that I just can't force Everything to create new DB somewhere and quit... If someone have UDF for this tool I will be happy to test it.

Thanks in advanced.

Sounds like it could be used for bad things, and it may well be in breach of many workplace network policies. Useful as it is, Everything is not a safe application in a multiuser environment. Because it requires access to the NTFS change journal, Everything must run with administrator privileges, either in a privileged user account or as a Windows service. As a Windows service it can expose search functionality to accounts without administrator privileges. However, Everything doesn't filter search results by client privileges before displaying them, so that every user can see every file on a volume, just as if they were using Everything in an administrator account themselves. Furthermore, a user can double-click a file name in the Everything results list to open the file or run it, if it is an executable, and Everything will launch the file with its own administrator credentials rather than with the user's own credentials. Although there may be a way to prevent privilege escalation when opening a file, there is no obvious remedy to prevent one user from listing the private files in another user's account.

Edited December 23, 2009 by contrex

[littleclown]

Hello.

Thanks for the remark.

I am some kind of system administrator of many many servers, and my job is to check install and troubleshoot applications there. Thats why I use Administrative credentials anyway. I already have 1000+ line script to install and check almost everything on every server (with administrative credentials), and there is no network restrictions for my account. As I already said the computers that I need to search are servers - only administrators have any access there. Everybody who have an account there already can see and start every file. I will make a script who will paste "everything" there, will search and will delete the exe files and db file just after that.

[littleclown]

Here is what I have for now:

;SET MAIN VARS
$FQDN="server"
$SEARCH="test.txt"
$drive="C"
$db_file="\\" & $FQDN &  "\" & $drive & "$\temp\everything.db"

;COPY EVERYTHING ON REMOTE LOCATION
FileCopy(@ScriptDir & "\es.exe", "\\" & $FQDN& "\" & $drive & "$\temp\")
FileCopy(@ScriptDir & "\everything.exe", "\\" & $FQDN& "\" & $drive & "$\temp\")

;START EVERYTHING MAIN EXE
run(@ComSpec & " /c psexec  \\" & $FQDN &  " " & $drive & ":\temp\Everything.exe")

;WAIT EVERYTHING TO START NEW DB FILE
Do
    $filesize=FileGetSize($db_file)
Until $filesize<>0

;WAIT DB FILE TO STOP GROWING UP
Do
    $filesize=FileGetSize($db_file)
    sleep(100)
Until $filesize=FileGetSize($db_file)

;START SEARCHING WITH EVERYTHING COMMAND LINE TOOL
RunWait(@ComSpec & " /c psexec  \\" & $FQDN &  " " & $drive & ":\temp\es.exe " & $search & " > " & @ScriptDir & "\LOGS\search.log")

;KILL EVERYTHING EXE FILE
Runwait(@ComSpec & " /c pskill  \\" & $FQDN &  " everything.exe")

;DELETE ALL EVERYTYING FILES
FileDelete("\\" & $FQDN& "\" & $drive & "$\temp\everything.exe")
FileDelete("\\" & $FQDN& "\" & $drive & "$\temp\es.exe")
FileDelete($db_file)

This is quick and dirty way, and I need to optimize it. For example I am not sure what will happen if there is app that makes and deletes file non-stop. Maybe the loop that wait for DB file to stop growing-up will never stop. Any ideas are welcome.

Edited December 23, 2009 by littleclown

[Davegbuf]

Have you tried the ETP/FTP server features under the Everything>Tools menu? These features are for remote systems.

[BrewManNH]

Davegbuf, I'm not sure if you're aware of this, but this thread is 4 years old and the 2 participants in it haven't been here in nearly 2 years.