Hi all,
Anyone know how to search a file on harddrive?
I mean, search on every folder.
Hi Onan,
Here is a nice tool :
SearchMyFiles v1.55 - Alternative to 'Search For Files And Folders' module of Windows + Duplicates Search
http://www.nirsoft.net/utils/search_my_files.html
Agent Ransack (http://www.mythicsoft.com/page.aspx?type=agentransack&page=home)
XTREE/ZTREE
Did you mean functionality? ie FindFirstFile API
http://msdn.microsoft.com/en-us/library/aa364418(VS.85).aspx
lol - maybe that's what he meant
in that case, a nice recursive is in order :P
too funny - we all give him names of our favorite search tools
If it is in asm,I have one who can do that (write by me)
else,more simple is the dos command "dir /S/B nameoffile.ext" on all the disk
I guess I need to learn about recursive.
a recursive search is a search in all directories.All you have to do is recall the same function (the function call itsef))when you find a directory.Take care of the stack,she can grow fast.
needed stack space=(Stack space needed by the function) * (Number of directories)
Quote from: ToutEnMasm on November 08, 2010, 09:04:44 AM
a recursive search is a search in all directories.All you have to do is recall the same function (the function call itsef))when you find a directory.Take care of the stack,she can grow fast.
needed stack space=(Stack space needed by the function) * (Number of directories)
How much space windows spare for stack?
Hi farabi,
Stack space is not really an issue, since a recursive directory search function only needs to set aside space on the stack for a single handle there is space on the normal Windows stack for a lot of recursions. Also since the recursion is through the chain of directories the stack is loaded while moving down through nested directories and is unloaded while moving up. So the only way you could have a stack overflow is if you have a folder that is nested thousands deep, not a likely scenario. I have a recursive directory search with callback in my files.lib library that works pretty well.
Edgar
Quote
How much space windows spare for stack?
Quote
Stack space is not really an issue
The space required in stack is the total size of arguments passed to the proc + the size of locals variables+ few dwords to put the return adress save ebp ...
Windows take care of stack overflow with an enough amount of stack memory and some others features,not a reason to ignore it.
To fix idea:
a windows prog,compiled wit ml 10 begin with a 3000h size of stack = 49 * MAX_PATH
You can verify this with the attached file
Quote from: ToutEnMasm on November 08, 2010, 02:31:35 PM
To fix idea:
a windows prog,compiled wit ml 10 begin with a 3000h size of stack = 49 * MAX_PATH
You can verify this with the attached file
I never actually said it could be ignored, it simply isn't an issue with so small of an amount of stack based data. There are only 24 bytes pushed onto the stack in a recursive folder search, 3 parameters, the return address, EBP and one handle (WFD). Not sure why you are worried about MAX_PATH, there is never a need to push a file name onto the stack or anything that large.
This is a source i once do for search for a specific kind of file and encrypt it + recursive search:
.Data
ScanType DB "*.*", 0
DataPath DB "./data/", 0
.Code
FindFiles Proc Path:DWord
Local Info:WIN32_FIND_DATA
Local fHandle:DWord
Local ArchiveNoFileOff:DWord
Local PathLastFolderOff:DWord
Invoke szCopy, Path, Offset ArchivePath
Invoke szLen, Offset ArchivePath
Lea Edx, ArchivePath
Add Edx, Eax
Sub Edx, 3
Mov ArchiveNoFileOff, Edx
Invoke szLen, Path
Mov Edx, Path
Add Edx, Eax
Sub Edx, 3
Mov PathLastFolderOff, Edx
Invoke FindFirstFile, Path, Addr Info
.If (Eax == INVALID_HANDLE_VALUE)
Xor Eax, Eax
Jmp @End
.EndIf
Mov fHandle, Eax
.Repeat
.If (Info.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY)
.If (Byte Ptr Info.cFileName == '.')
Invoke FindNextFile, fHandle, Addr Info
.If (Eax == 0)
.Break
.EndIf
.Continue
.EndIf
Invoke szCopy, Addr Info.cFileName, PathLastFolderOff
Invoke szLen, Path
Mov Edx, Path
Mov Byte Ptr [Edx+Eax], '/'
Mov Byte Ptr [Edx+Eax+1], 0
Invoke szCatStr, Path, Offset ScanType
Invoke FindFiles, Path
Invoke FindNextFile, fHandle, Addr Info
.If (Eax == 0)
.Break
.EndIf
.Else
Invoke FindExtension, Addr Info.cFileName
.If (Eax == 0)
Invoke FindNextFile, fHandle, Addr Info
.Continue
.ElseIf (Eax == 1)
Invoke szCopy, Addr Info.cFileName, ArchiveNoFileOff
Invoke FindPath, Offset ArchivePath
.If (Eax == 0)
Invoke FindNextFile, fHandle, Addr Info
.Continue
.Endif
.Else
Invoke szCopy, Addr Info.cFileName, ArchiveNoFileOff
.Endif
Invoke ReadThisFile, Offset ArchivePath
.If (Eax == NULL)
Invoke FindNextFile, fHandle, Addr Info
.Continue
.EndIf
Invoke EncrypThisFile, Eax, Edx, Ecx
Invoke FindNextFile, fHandle, Addr Info
.EndIf
.Until (Eax == 0)
@End:
Ret
FindFiles EndP
FindExtension is just a proc for find the extension of the file (no need for paste it here).
Anyway hope it could help you. :U
Quote from: donkey
Not sure why you are worried about MAX_PATH, there is never a need to push a file name onto the stack or anything that large.
Indeed, I've done it before in a single buffer, and just pass down the pointer to the leaf within the path (ie the end). The path gets built and torn back down as the recursion descends, and comes back. No need to copy or stack the path, or compute the string length.
Quote
Not sure why you are worried about MAX_PATH, there is never a need to push a file name onto the stack or anything that large.
there is further soluces to pass arguments to FindFirstFile ,adress ,value ..
adress is my prefered but passed them by values is not wrong
So This give a unit more speaking about the problem,that all.
Quote from: ToutEnMasm on November 08, 2010, 02:31:35 PM
To fix idea:
a windows prog,compiled wit ml 10 begin with a 3000h size of stack = 49 * MAX_PATH
You can verify this with the attached file
Looks like brainless method... (No offence) Dont really expect somebody doing a recursion by copying the new string file into a different stack pointer?...
Good method is using stack but later adjusting the pointer to the begin of the older string on the next recursion procedure. In that way dont need to worry about nothing.
The recurse procedure can be use for further things,it's for that i have speak about the stack.
Here is a sample of mine who use a very few memory stack and can be insert easily in another prog who have perhaps big need in stack.
Quote from: ToutEnMasm on November 08, 2010, 08:52:04 PM
The recurse procedure can be use for further things,it's for that i have speak about the stack.
Here is a sample of mine who use a very few memory stack and can be insert easily in another prog who have perhaps big need in stack.
I never found myself on the situation of using stack for even more than 32 bytes (8 arguments of DWORD size). I think its a universal programming method to avoid using stack for larger memory operations, for that you can use the heap or allocate virtual memory, while saving the pointers on the stack and retrieve them (mostly of what is intended for).
Still you can change SizeOfStackCommit under the PE format and use stack for odd ideas...
Cant find a recursive example when you need to use stack for such large operations, only in the very strange case you wanted to save each file name path without override the last pointer of the buffer holder and push on the recursive proc the older string path that would give you:
1000h (SizeOfStackCommit) / 4 = 400h size for saving pointers. Though that idea is crazy, you can do everything about recursive by override the old pointer. (and never worry about stack (in size matter) )
PS: I think the word "recursive" gives the whole description. Something recursive NEEDS to have the same a recursive algorithm inside if not, its not recursive...