Path not found error using FSO GetFolder

[J Talbot]

Hi

I'm using a script to get a list of folders (and subfolders) for a UNC path
but I noticed that if the script tries to get hold of a subfolder path that
is too long to display then it ends with 'Path Not Found' - so the script is
:

Set objFSO = CreateObject("Scripting.FileSystemObject")
objStartFolder = "\\server4\files"

Set objFolder = objFSO.GetFolder(objStartFolder)
Wscript.Echo objFolder.Path
Wscript.Echo

ShowSubfolders objFSO.GetFolder(objStartFolder)

Sub ShowSubFolders(Folder)
For Each Subfolder in Folder.SubFolders
Wscript.Echo Subfolder.Path
Set objFolder = objFSO.GetFolder(Subfolder.Path)
Wscript.Echo
ShowSubFolders Subfolder
Next
End Sub

If I add 'On Error Resume Nex't at the top, then it doesn't display the
error but the script just exits on the problem path again and won't go any
further. I unfortunately don't have the means to change the path structure
and make them smaller or use mapped drive etc. What I effectively need is
the script to ignore any paths that cause a problem and just carry on with
the next.

Is there any other way of getting round this?

Thanks

John

[Anthony Jones]

"J Talbot" <talbo...@gmail.com> wrote in message
news:46dd213a$0$22126$9a6e...@unlimited.newshosting.com...

Use a separate function to isolate the code overwhich the Resume Next should
be active:-

Function GetFolderFromPath(Path)

On Error Resume Next
Set GetFolderFromPath = Nothing
Set GetFolderFromPath = objFSO.GetFolder(Path)

End Function

Now your function becomes:-

Sub ShowSubFolders(Folder)
For Each Subfolder in Folder.SubFolders
Wscript.Echo Subfolder.Path

If Not GetFolderFromPath(Subfolder.Path) Is Nothing Then
Wscript.Echo
ShowSubFolders Subfolder
End If
Next
End Sub

Of course you could just delete the line that assigns objFolder from
GetFolder since objFolder isn't being used. Why do you want to skip these
folders? In what way is the result useful with missing information?

--
Anthony Jones - MVP ASP/ASP.NET

[J Talbot]

Thanks but this still errors with Path not found on the long UNC path after
listing the previous subfolders, here's what I used after your modification
:

Set objFSO = CreateObject("Scripting.FileSystemObject")

objStartFolder = \\server\files

Set objFolder = objFSO.GetFolder(objStartFolder)
Wscript.Echo objFolder.Path
Wscript.Echo

ShowSubfolders objFSO.GetFolder(objStartFolder)

Function GetFolderFromPath(Path)

On Error Resume Next
Set GetFolderFromPath = Nothing
Set GetFolderFromPath = objFSO.GetFolder(Path)

End Function

Sub ShowSubFolders(Folder)
For Each Subfolder in Folder.SubFolders 'Path Not Found error on this
line

Wscript.Echo Subfolder.Path
If Not GetFolderFromPath(Subfolder.Path) Is Nothing Then
Wscript.Echo
ShowSubFolders Subfolder
End If
Next
End Sub

This is just a test script for part of another project where I need to list
files in folders, however, I need to ignore folders that can't be accessed
and let the script continue for folders that can.

Any other thoughts on the above ? - is it correct ?

Thanks

John

"Anthony Jones" <A...@yadayadayada.com> wrote in message
news:%23C2YcZt...@TK2MSFTNGP05.phx.gbl...

[J Talbot]

Should add that this is the correct line in the script

objStartFolder = "\\server\files"

"J Talbot" <talbo...@gmail.com> wrote in message

news:46dd2e4b$0$3147$9a6e...@unlimited.newshosting.com...

[Paul Randall]

"J Talbot" <talbo...@gmail.com> wrote in message
news:46dd213a$0$22126$9a6e...@unlimited.newshosting.com...

Few people understand VBScript's error handling. Most people who think they
do are wrong.
By default, the system handles errors by displaying an error message and
exitting. The 'On Error Resume Next' statement turns off the system error
handling and turns on user error handling. With the system error handling
turned off, if the code never checks the Err object, then Nobody is handling
the errors. But that doesn't mean what you think it means. Most people,
whether they read the help file or not, think that the 'On Error Resume
Next' statement does what the help file says: "On Error Resume Next causes
execution to continue with the statement immediately following the statement
that caused the run-time error, or ...". They think it means the stuff
before the ', or ...' at the end of what I just quoted because that is the
part they want it to mean. Plus, the 'or ...' part is hard to understand.
This part reads ", or with the statement immediately following the most
recent call out of the procedure containing the On Error Resume Next
statement." For most of us, it would take a 20 page white paper and many
sample scripts to understand the implications of the ', or ..." part.

I suppose that lots of experienced scripters understand the first part --
"On Error Resume Next causes execution to continue with the statement
immediately following the statement that caused the run-time error".

Without other code to modify its effects, the 'On Error Resume Next'
statement is a powerful way to hide the possibility of knowing when and
where errors occur. Many people use it after testing their code to trick
the end user into thinking this "error free code" is running perfectly.
What few people understand is that at certain locations in the code, that
lack of error handling can cause unforseen or harmful effects.

One simple example is the If ... Then ... Else ... End If structure.
Suppose your code turns off system error handling and an error occurs in the
If statement of this block of code. "Execution continues with the statement
immediately following ..." means that the 'true' block of code is executed
because this follows the If statement. But what about the Else block?
Maybe it is executed too? Only experiments will tell; the scripting help
file doesn't.

Hopefully you see the futility of just using an 'On Error Resume Next'
statement. My suggestion is that you remove that statement from the
beginning of your script, and then repeatedly run the script and analyze the
errors you get, then isolate those statements within a block of code like:
On Error Resume Next
<line in question>
If Err.Number = <some error number you know can be ignorred> Then
'do nothing
Else If Err.Number = <some other error number you know can be ignorred> Then
'do nothing
Else If Err.Number = <some error number you know how to handle> Then
<code to handle this error>
Else If Err.Number = <some other error number you know how to handle> Then
<code to handle this error>
Else
<code to display/handle/'quit execution' due to this new error you
haven't come across before>
End If
On Error GoTo 0

By refining your code to handle each error as it occurs, you may find that
your real problem may not be what you think it is and can learn to make your
code more valuable.

-Paul Randall