Printable View
Hey all,
Just got back into VB a bit recently, having issues with the findfirstfile, findnextfile API's.
I have an app that is working fine on my own drive, however when using the app at work to search a networked drive, i get no results back, nor any errors.
Are there any known issues with using those API's to search a readonly network'd drive?
I haven't found anything that would suggest so...
Thanks,
Is the network shared? Are you using a mapped drive or UNC paths? More details could be helpful, maybe including a sample path string you are trying to search.
Regarding errors:
1) If the API failed, it will return -1 (INVALID_HANDLE_VALUE)
2) You can test for errors by using GetLastError DLL or even possibly with VB's Err.LastDLLError
An example path.
"\\nwdrv1\Eng\Web\1st_Teams\1a_Eng\Software\Builds\Releases"
I will assume its a UNC path. I have a batch file working that searches fine, however i had to use pushD command to access the path, due to being unc i believe.
I also have the INVALID_HANDLE_VALUE already in my code, but it hasnt returned. so i assumed all was well.
i can post my code later once at home.
Code:Public Sub Search(pstrMask As String, ByVal pstrFolder As String)
Const MAXDWORD = &HFFFF
Const INVALID_HANDLE_VALUE = -1
Dim strFile As String
Dim lngHandle As Long
Dim intSearching As Integer
Dim typFind As WIN32_FIND_DATA
DoEvents
intSearching = 1
lngHandle = FindFirstFile(pstrFolder & "\*.*", typFind)
Do While lngHandle <> INVALID_HANDLE_VALUE And intSearching <> 0 And Not mblnCancel
strFile = Left$(typFind.cFileName, InStr(typFind.cFileName, vbNullChar) - 1)
If (typFind.dwFileAttributes And vbDirectory) = vbDirectory Then
' Recurse subfolder
If Left$(strFile, 1) <> "." Then Search pstrMask, pstrFolder & "\" & strFile
ElseIf strFile Like pstrMask Then
' Found matching file
sSearchValue = searchTxt.Text 'Value you are searching for
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFileStream = objFSO.OpenTextFile(pstrFolder & "\" & strFile, 1)
sFileBuffer = objFileStream.ReadAll
If InStr(1, sFileBuffer, sSearchValue, vbTextCompare) <> 0 Then
bValueExists = True
Else
bValueExists = False
End If
objFileStream.Close
Set objFileStream = Nothing
Set objFSO = Nothing
' end test here
If bValueExists = True Then
Me.lstResults.AddItem pstrFolder
End If
End If
intSearching = FindNextFile(lngHandle, typFind)
Loop
lngHandle = FindClose(lngHandle)
End Sub
There is my search sub im using to perform a recursive search through the directory. It starts its search in the path i pass it, and searches for the file i pass it. which is a text file, and then once the text file is found it will search through that text file for a keyword, and if found. adds the path to a listbox. then continues on its recursive search.
Like I said previously, working fine on my computer at home on my own drive. But when using it at work with the actual networked drive path being passed to the sub, no results are ever displayed in the listbox.
My only thought is maybe the invalid handle value is returning -1, since i dont actually error check explicitly for it, just to only do the search if the value ISNT -1 for the handle.
any thoughts?
I'll take a look tomorrow morning. Others may chime in before then.
In the mean time, just before you recurse a subfolder, add this line to see if you are actually doing that
The length being printed out above, by the way, is just to see if you are reaching max path lengthCode:Debug.Print pstrFolder & "\" & strFile, Len(pstrFolder & "\" & strFile)
Edited: Is \\nwdrv1\Eng a shared folder?
It is shared. however, the pc's the app will be run from, only have read-access to that entire drive. I've gotten a batch file that works searching for what i need. I just wanted to do a GUI version, and dont see why id have problems with the APIs. Ill add the line above to test at work and see what results i get, if any.
Ok, let us know.
also add a check here
after this line: lngHandle = FindFirstFile(pstrFolder & "\*.*", typFind)
add this line: If lngHandle = INVALID_HANDLE_VALUE Then MsgBox "FindFirst Failed"
If that msgbox appears, you can press Ctrl+Break and break into the code at that point. You can then determine what the current value of pstrFolder & strFile are to gather more clues. At that point and within the debug/immediate window, you may want to see if Err.LastDLLError returns anything.
That will be the only issue, I don't have VB installed on my work computer. Thus testing is a tad bit difficult.
I did run the test app, with the line you gave previously, used msgbox instead of debug. it gave me back the correct path that i passed it to the drive. however i may need to check further down, as i dont know if its going into all the subfolders in that drive.
Well, instead of a msgbox, suggest this....
Write to a non-protected folder on the user's drive, i..e, Open [path/file] For Append As #3. Then write debug info & close file.
If FindFirstFile returns -1, write the full path & file name & character count.
If FindFirstFile does return -1, your loop will abort at that subfolder level, so no further subfolders (if any) will be recursed.
I don't see any error handling in that routine, so if objFileStream failed, you'd probably get a crash in a compiled app, unless whatever routine calling this function uses On Error Resume Next. Otherwise, I'd suggest testing for that situation too.
With some simple debugging, I think you can narrow this down and figure out what's broke.
I'll check again tomorrow at work, I've added some code to error check a bit to see if there is something going on within the search.
My main concern was that maybe there was an issue using the api's with a networked drive, since it works fine on my home pc, when i use a path to my desktop where i setup a similar folder structure with test files.
I also read this at http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
Hoping I won't be having an issue due to that.
portion from the msdn page.
I highly doubt I'd ever be nearing the 260 character max path length though, the deepest the subfolders would ever go is maybe 4-5 subfolders beyond the starting point.Quote:
Note The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.
The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.
There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.
When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12).
The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not be able to interpret properly.
Guess i'll find out more tomorrow when I can test at work again. :afrog:
Shouldn't be. I ran your code at work on a networked UNC path, similar to yours, and expected results were returned. Though I have read/write access, but you are requesting your FSO object to open files for reading & I wouldn't expect an error if your customer has read access to those folders/files.Quote:
Originally Posted by ice_531
To sum up, I can think of 3 possible reason for failure
1) Invalid start path?
2) No read permissions at folder and/or file level
- If folder level, FindFileFirst should return -1
- If file level, Set objFileStream = objFSO.OpenTextFile(pstrFolder & "\" & strFile, 1) should fail
3) Obvious answer & not the case here I think: actual files matching criteria not found and/or text within file not matching critera
I kept with my msgbox test just before the recursive line. and just walked the program through folder by folder that way. (i did add a vbyesno style, so i can stop it via my boolean value when wanted)
I was able to return a result into my listbox just fine. i chose a folder and text file about 2 directories down, and 3 subfolders deep. It msgboxed the correct path through all these folders. Then it added the folder found to my list. so that worked fine.
However, I then chose a text file criteria further down, and i walked it through...but it never found the text for some reason. So there seems to be no problem with the actual recursive searching of the folders...as it is going into every folder. It seems to be a problem with my actual portion once the readme file is found.
[VBCODE]
' Found matching file
sSearchValue = searchTxt.Text 'Value you are searching for
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFileStream = objFSO.OpenTextFile(pstrFolder & "\" & strFile, 1)
sFileBuffer = objFileStream.ReadAll
If InStr(1, sFileBuffer, sSearchValue, vbTextCompare) <> 0 Then
bValueExists = True
Else
bValueExists = False
End If
objFileStream.Close
Set objFileStream = Nothing
Set objFSO = Nothing
' end test here
If bValueExists = True Then
Me.lstResults.AddItem pstrFolder
[/VBCODE]
Soooo. Now I'm going to have to figure out what could be wrong there, that would not work for some reason here in a folder further down. still not making much sense, seeing as how it works fine at home and such.
Maybe test these two scenarios then....
1) Notify yourself if a matching file was found. Honestly I don't know if the following line is case-sensitive or not:
strFile Like pstrMask
2) If file found and after reading into sFileBuffer, Notify yourself with the first 20 or so characters of sFileBuffer to see if any unexpected characters exist (unicode/ansi issues possibly?)
If you do have any error trapping in the routine or within the calling routine (i.e., On Error ...), ensure your error check adds some notification if an error occurs
I'm willing to bet my issue is something really simple. I'm thinking that my sub that actually calls the search function, is activating the next function, which actually searches the hidden listbox used by the Search function, and then adds certain things to my visible listbox based on the 2nd search.
However, would me using msgboxes be the reason i can get results? Where as if i use my other app, with the exact same code aside from those msgboxes to test. i get no results.
This is the only difference I can think of. I guess I won't be able to know any further until I get back home and can look at my code and try some things to test tomorrow.
Regarding your comments about hidden listbox and sub that "acutally calls"... Can you elaborate more? If not with code, with simple pseudo-code then.
You aren't using timers to conduct any portion of the searches are you?
If you enter the search routine from another outside call while the currently active search hasn't finished; not sure if you'd get unexpected results or not. If you think that is happening, prevent it from happening and see if results are different.
Basically.
I have 2 list boxes. 1 is hidden, lstResults. This one is actually used in the Search code you've seen above.
The 2nd listbox is simply, list2. This one is used to display the final results. Which it conducts another search on the results displayed in lstResults. It picks out which list items it needs to from lstResults and then displays them in list2.
my actual code in my button that begins all of this searching is pretty much.
I'm not using any timers, So should I place the list2list call at the end of the other search. I didn't know if the above would be an issue, would the list2list function get called after search finished, or no?Code:search "readme.txt", "thefilepathtothenetworkdrive"
call list2list
The way you have it appears to be fine
The list2list call won't occur until after the recursive search is done.
I can't replicate your problem. Using your code as-is, works ok for me. You may opt to make lstResults visible during your testing so you can see whether it is populated with/without the msgboxes running as that will answer one of your questions you were thinking about. And you might want to add 2 temporary new listboxes: one that gets populated with every subfolder name you routine searches; and the other with the file names that match your filter. That should narrow your focus a bit: without the msgbox code, either your code is searching not searching folders, and if it is, then it is not opening the files it found, or not finding the text within the files.
That's what I was thinking, that the next line wouldn't execute until the Search recursive had completed.
However, doesn't seem to work like that for some reason. The other app i told you I have here at work, i have the lstResults visible. I never see it populate. Yet when i use the msgboxes, and step through it msgbox by msgbox, i end up getting results in list2. Doesn't make any sense, I keep making different versions of the app so i can try to debug once im at work. I will check again when I get home, and compile several different exe's with different methods of testing i guess.
This would be a lot easier if I could get approval to get VB6 installed on my work pc, still waiting on that sadly. :rolleyes:
By using the additional listboxes, you'll know which parts are failing. As I see it, you have 3 basic parts
1) Identify subfolders and recurse them: add each to listbox before it gets recursed to validate
2) Within a folder, pattern search for matching files: add each match to listbox before reading to validate
3) Reading the matched text file. Already added to lstResults
Without the msgboxes in play. The point of failure will be identified by whichever listbox isn't populated. Of course, ensure at least one file exists that matches your criteria.
Ok. Been testing more at work when I've found time to do so.
It isn't recursing through all of the folders. It makes it down to the 6th directory in that main folder. It goes through all of those first 6 directories subfolders just fine. But then it starts back over at the very 1st directory for some reason. I see no reason why it would be doing this from the search code?
This would be why i am able to test for results for the first few folders but not past.
Any ideas, from the search code, why it would ever start back over at the very top directory, after reaching the end of the 6th?
I think i'm going to narrow my initial path search, by using another user input choice. So that i can start the search, 1 directory deeper than im currently doing, and it will make the search faster too.
I'd still like to know why the search code isn't working as is though! :)
I guess you have to use APIs:
vb Code:
I resolved this, simply by narrowing my search prior to calling the search function. Seems to be working just fine now, for all 18 parent folders and their subfolders.
Still unsure why the search was having issues without doing this. Doubt I'll be finding out anytime soon, without having a copy of VB here at work :afrog:
Thanks for the help though LaVolpe!
You're welcome. You might want to convince your boss to allow you to load your own personal copy of VB at work. You can get the service packs from the web (MSDN). For justification, simply show him/her the stuff you've already done and let him/her know you'd like to be able to maintain them.
Quote:
Originally Posted by LaVolpe
Sadly, we can't load our own copies on the computers at work. I'm still waiting approval to get a licensed copy of vb6 installed. In other words, waiting on word from Engineering to see if they have another available copy. If they can't find one, don't think it will happen...since you can no longer purchase a license for vb6. They would be willing to purchase one, I was told.:lol:
Just one more question regarding your problem. The server you are searching, is it a 64 bit operating system? If so, jump back to this MSDN link and towards the bottom look for the Wow64 API to call.
Also, you are creating a new scripting object every time you need to open a file. A bit of a slow down overall. Recommend creating the objFSO before you call your search routine, then destroy it after search routine returns vs. creating many times within the recursion.
If this is resolved for you, please mark it as such by using the Thread Tools menu near top of your first post.
Good luck.
All the computers at work are XP sp3.
heh, didn't know they had added that Thread tools button to the forums. Been a long time since I was active on these boards!
note: thx for the tip on the FSO. didn't even think about it, I've thrown this app together pretty quickly