Check if File or Folder Exists takes too long on network folder

[egraham]

Does anyone have any experience using the Check if File or Folder Exists function on a network folder? I use it to see if a computer on the network is connected. If so, it grabs a file off that computer and performs a calculation.

If that remote computer isn't on, it takes upwards of a minute for the function to come back and let me know the file/folder doesn't exist. It hangs that VI and structure it is in for the entire time. I'm trying to think of a way to check to see if a remote directory exists and time out if it hasn't found it within a few seconds.

I've tried the OpenG File Exists function with similar results. Both hang the code for too long if it can't find the remote directory.

Thanks in advance,

Eric

[Wart]

In Windows you might use system exec to try and see if you can list the files in the directory or somewhere on the same network drive.  Something like cmd /c dir S: might work.  You'll either get a list of files and folders or a failure message like "The system cannot find the path specified." 

This seems like a terrible work around to me, but it should be pretty fast.  Surely someone knows a better way.

[PaulieQ]

Eric,

It works ok in my case. I have an application that saves some test reports on local PC or on the server. First it checks if the Server Folder exists. If yes saves the report on the server (equivalent with network available), otherwise local. I haven't noticed any problems or delay even when the server was shut down for maintenance or other causes. 

Paul 

[Mark_Yedinak]

The delay you are experiencing is most likely a DNS lookup. This has nothing to do with LabVIEW. Since you mentioned you are looking for a remote computer I assume you are doing this by name. Actually I have seen cases where a DNS lookup can occur even when you have the IP Address but this is rare. If you are using the DNS name then you need to wait for the name resolution to complete and this can take time.

[rolfk]

It think the problem is deeper than just a DNS lookup. LabVIEW simply uses Windows File API functions to do its file IO operation. It has a few workarounds for some rather nasty troubles when using file API functions on network paths but in general does not go through special code when a path refers to a network location. The network API used by the Windows file IO API for network paths is however quite old and mostly synchronous. It is from the days NetBEUI was still the default network protocol under Windows. These functions work with long timeouts to allow for slow network connections like dialup. So what really happens is that the file IO API invokes some synbchronous network API with a long timeout to locate the network resource and query its attributes or enumerat its contents.

The only way to go around that is by invoking the correct network API directly. If it is an TCP/IP network resource you can most likely get away by simply extracting the TCP/IP network name from the path and do a simple TCP/IP connection attempt with short timeout. If it is a Windows network resource things get possibly a bit more complicated since not every Windows network resource can be easily translated into a TCP/IP name. Most likely there is usually some involvement of Windows networking API calls to do that.

[Greg_S-Video]

Hello egraham

Have you been able to experiment with any of the suggestions by our esteemed forum users?  Please let me know your status on this issue.  For our records, could you please provide the version of LabVIEW you are running and the operating system you are using.  If you are still having issues, you may wish to post a sample VI illustrating your issue.

Thank you very much for choosing National Instruments!

[egraham]

This one is still on my plate. As soon as I experiment with the suggestions provided I'll post my findings here. Thank you for all the suggestions!

Eric

[Greg_S-Video]

Hello Eric

Thank you very much for your response, I look forward to your progress.  All the best.  Please keep me in the loop!

[egraham]

I'm going to assume that Rolf is on to something and provided a good description of what is occurring.

I tried TCP Open Connection, but it always output an error, even when the remote computer was available. I tried what I believe are common ports, but I'm not sure I ever had the right one.

I ended up just pinging the remote computer to see if I got a response. The path I was trying to get to was 10.50.3.50/Export CSV, so I just pinged the static IP, 10.50.3.50.

There's a ping example here that uses the System Exec VI to see if the remote computer will respond. It seems to be working with good results and if the computer is disonnected it let's me know very quickly and I can free up the structure to perform other tasks.

https://decibel.ni.com/content/docs/DOC-15341

Again, thanks for all your help.

Eric

[Sidd]

The Ping.vi works great.  I'm using it.  I had a similar issue with "Check if file or folder..." taking too long.  Thanks.