Invalid UNC path freezes scripts

[bluespirit]

Hi,

I'm writing a script to copy a number of files from UNC paths. That bit is pretty simple. However, my users think my script has crashed, which it hasn't, it's only because the UNC path doesn't exist and one of the AutoIt functions is waiting. This is true of FileExists(), FileCopy(), DriveStatus(), etc.

Is there a function to check if a UNC path exists that doesn't pause in this fashion?

The only way round it, that I can think of at the moment, is to spawn another process and pre-check all the UNC paths and write if they exist in a text file. Then rather than use FileExists(), I use my text file instead.

Anybody got a better idea?

Thanks,

James

[jchd]

You're are not in a domain, are you? I doubt pre-checking things would make the whole process more responsive.

The problem is probably not linked to AutoIt but instead has its root in how a peer LAN (without a domain) works. I guess your script is not hung, and that the AutoIt functions (which are likely more or less simple wrappers around Windows calls) are simply waiting for Windows function to return.

I've had a number of such irritrations when Windows decides that there is no more a Master Browser (Google for that) and it has to proceed to a Master Browser election. In MS parlance that means _almost_ locating a PDF (virtual to save trees) printer, print election bulletins, distribute them to the whole network where some computers can be badly drunk and sleeping hard, wait for the election results, proclaim the new King lound and pass the LAN crown to the newly elected Master Browser, which can only then decide which address the server you request has...

Of course all of this takes time, but I'm not sure that AutoIt is to blame here. There are many more details hidden, like the use of LMHOST defs, and more.

BTW, most MS peer LANs work without Master Browser, which is something I find funny. I may be off somewhere in the above pseudo-rationale but the only thing to know is that a MS peer LAN can take much time to answer initial request on/for a given server. This is part of a long tradition of MS network protocols to be unreliable, slow, ineffective and completely off any standard. But as a long-term Windows users you and me now have some hard time finding that abnormal

Of course, enterprise networks don't work this way!

[bluespirit]

Funny you should mention enterprise domains as that is what the script is running on. All the valid UNC paths return immediately. It's the invalid ones that take their time before giving up.

As you say, it's not an AutoIt issue, but a Windows one. I'm trying to find a creative way around the problem. The method I mentioned wouldn't be any quicker, it's just it would be another script running in the background gathering all the required information that the user wasn't aware of. The main script could then reference that information to get a quicker response than asking Windows direct. What do you think?

[jchd]

Sorry I don't have good AD experience to help you on this.

I thought that a correctly setup domain would tag invalid UNCs right away, and all large corp MS networks I've seen used to work (or rather fail) decently fast in such case, but this is outdated experience. All trolling about MS apart, I suspect there should be settings in your DC to rule out bad UNCs quickly but it may need to determine what is causing the delay: bad server, bad path, bad rights.

BTW, good UNCs & rights are sometimes causing the same irritating delay issue on a MS peer LAN. Hence my mention of Master Browsers. But this is probably unrelated to your situation.

I hope someone more knowledgeable will take over the issue and offer a smart and solid solution.

I whish you best of luck.