How to wait out network lag on file write?

[Gan Uesli Starling]

Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail.

 

I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet.

 

My temporary work-around is to open a Windows file browser to that path, the twiddle my thumbs until the file list populates. Then, the path being established, I may safely start the parent VI of which this VI is a sub.

 

Any ideas?

Write_HTML.vi

[Rolf Kalbermatter]

Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail.

 

I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet.

 

Any ideas?

 

Except going directly the network path? Not really! There might be some obscure registry setting which influences the timeout, but in my experience the default timeouts for accessing remote file paths through Windows file API are rather to long than to small. I don't like to wait for 1 minute to finally get an error that a file path is not currently accessible since the network or remote server is down. Identifying that registry setting is going to be difficult and made extra complicated as it may vary depending on your current setup and logged in credentials.

 

That file API is layered on top of the kernel API which is layered on top of the NetBEUI protocol, which then makes use of Winsock, which then calls into the socket driver and from there in the network card driver. NetBEUI is/was a nice invention back in the days of DOS and got carried over since, but it did not have a rich control interface for things like timeouts, etc. It simply goes and sits for whatever time the developer found reasonable. The Windows file API does only support timeouts on its own level through asynchronous API calls, which is cumbersome and in most cases serves no extra purpose other than freeing up the current thread to do something else while the file API waits for the underlaying resource to become available. LabVIEW does not use the asynchronous file API since it doesn't give LabVIEW anything extra and even if it did, this is entirly seperate from possible timeouts in lower level file system drivers like NetBEUI.

 

Generally I would say your Windows domain setup is somewhat flaky, so that the NetBEUI driver can't always verify the access rights of the current user for the desired network resource in time. This setup used to be fairly straightforward in Win NT 4 times but got tightened up a lot since, so that it is very easy to make errors when configuring domain users and access rights, and this errors often only occur occasionally, depending on network load, actual login mode and various other temporary conditions.

[Gan Uesli Starling]

Very informative and to the point. Thank you.

 

I switched from \\Foo\ to \\ plus dotted quad, and it works fine now.

[Rolf Kalbermatter]

Very informative and to the point. Thank you.

 

I switched from \\Foo\ to \\ plus dotted quad, and it works fine now.

 

Well, then your NetBEUI to IP address resolution is not working properly. Your previous comment about going directly to the network path, I was actually more refering to entirely alternative protocols such as WebDAV or (S)FTP.