WebDAV Get File Error -124100 occurred at an unidentified location

[James@Work]

OK, I'm having more WebDAV issues...

I am using the WebDAV Synchronous VIs with Win7 and a cRIO-9014, LV 2013 SP1 and WebDAV Server 13.5.0.

When using the NI_WebDAV.lvlib:Get File.vi I receive an error even though the file is retreived successfully.  I don't want to start ignoring errors in my code since they might indicate some real issue now or with future versions of WebDAV.

I'm quickly learning that all WebDAV error messages are useless and since all VIs are locked debugging is impossible.

Has anyone located any useful help information for WebDAV error messages?

Thanks for any suggestions.

James

[James@Work]

And...

I just verified the same error when retrieving files from a cRIO-9030 with LinuxRT and WebDAV Server 14.0.0

James

[lucaso3]

Hello James@Fann,

Here are some links that you might find useful:

http://digital.ni.com/public.nsf/allkb/4EBE45E8A816B19386257B6C0071D025

http://zone.ni.com/reference/en-XX/help/371361K-01/lvcomm/webdav_get_adv/

http://zone.ni.com/reference/en-XX/help/371361K-01/lvcomm/webdav_sync/

On these forums you might find information about some issues that you might encounter using WebDAV, I understand that is not exactly your issue but we need to verify several things:

http://forums.ni.com/t5/Real-Time-Measurement-and/WebDAV-session-no-error-but-not-connected/td-p/254...

https://forums.ni.com/t5/LabVIEW/How-can-I-download-a-file-over-the-internet-from-a-WebDAV-server/td...

I was investigating a little about the issue that you have and everything that I found is regarding the way you have the address. In the first links is described how you need to set the path correctly.

Although I do not think this is an OS behavior, you should verify the functionality if the WebDAV for the different OS. In these links you might find information:

http://zone.ni.com/reference/en-XX/help/370622M-01/lvrtconcepts/rt_ets/

http://www.ni.com/white-paper/14626/en/

http://zone.ni.com/reference/en-XX/help/370622M-01/lvrtconcepts/rt_vxworks/

I really hope all the information listed in here might be useful to fix your issue.

Regards.

Luis Diego

National Instruments

[James@Work]

Luis,

Thanks, I am familiar with searching ni.com, the forums and using LabVIEW Help.

Regards,

James

[lucaso3]

Hello James@Fann,

What is the specific URI prefix that you have been using?

Have you tried running the example of LabVIEW called WebDAV Data Acquisition project? This might be a good step to see if you might encounter the same error. If you do not experience any message while running the example, we will need to double check your code to see how you are implementing this or if there is an error on how the file path is specified.

Regards.

Luis Diego

National Instruments

[James@Work]

Luis,

The format of my uri and relative uri are as follows:

For the Open Session.vi, the uri format is http://<target>/files (http://192.168.18.110/files)

For the Get File.vi, the relative uri for the file is the value returned by the Directory Listing.vi in the file list cluster

/files/ni-rt/startup/TestData/<filename>

As I said, the Get File.vi moves the file from the RT target to my Windows directory, so I am curious about why I receive this non-descriptive error.  If I had an error in the file path, I wouldn't expect the file to be found and retrieved.

Yes, I have looked at that project and the example finder VIs.  Unfortunately, they all use Asynchronous VIs, not an apples-to-apples comparison.

Thanks for the suggestions.

James

[James@Work · Accepted solution]

Luis,

OK, I just discovered the path returned from the Directory Listing.vi is apparently the problem.

I added code to strip the leading path "/files" from this path and the error is eliminated.

Evidently, the WebDAV VIs were written to work correctly with this incorrect path, but return a useless error.

The need to add this non-existent path section to the Open Connection.vi uri and then be required to remove it from the path returned by the Directory Listing.vi before using the Get File.vi seems like an oversite with the development of these libraries??  If this non-existent path is required by some lower-level function (locked diagrams) then this string could have been appended/stripped internal to the VIs in this library.

I hope finding the cause of each non-descriptive WebDAV error isn't as much fun.

Regards,

James

[James@Work]

Luis,

Just an FYI.

The Asynchronous Example has a custom VI (FileInfo to Name and Path.vi) for stripping off the non-existent files prefix from the uri returned by the Directory Listing.vi.  This VI should have been included in the WebDAV palette since removing this prefix is always required to avoid the non-descriptive error.  I'll add it to our shared tools WebDAV palette, along with my other WebDAV wrapper VIs that will allow my team to implement WebDAV much easier/faster.

Regards,

James