File System Web Service LabVIEW API - unexpected results

[WNM]

http://zone.ni.com/devzone/cda/epd/p/id/6466

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

The white paper referenced above explains how I should be able to use the referenced API example and the "fws/dirlist" "URL Mapping" to get information about a set of files in a remote directory (in my case on a cRIO).  Using the example VI's "Directory List" tab, I can indeed get this listing of the files in the specified cRIO directory. If no options under "options dirlist" are checked, then the internal POST vi that does the real work is called with these arguments:

        URL =    http://192.168.84.198:3580/fsws/dirlist

        data =    Param1=/c//labview data/arc_tandh_scissor_lift/&Param2=XML&Param3=
and this is the response that is returned:

<?xml version="1.0" encoding="UTF-8"?>
<directory name="/c//labview data/arc_tandh_scissor_lift/">
<directory name="logs">
</directory>
<file name="system-states_data.ini" />
<file name="housekeeping_state_data.ini" />
<file name="adv-pid_control_data.ini" />
<file name="rt_environment.ini" />
<file name="stepper_configuration.ini" />
<file name="scaling_and_filter_data.ini" />
<file name="md5 file checksums.ini" />
</directory>

Turning on the "show all details" option causes the POST vi to be called with these arguments:

http://192.168.84.198:3580/fsws/dirlist

Param1=/c//labview data/arc_tandh_scissor_lift/&Param2=XML&Param3=-a

but the response which is returned remains unchanged (same as above, no details!)

On the other hand, turning on the "show sizes" option causes POST to be called with these arguments:

http://192.168.84.198:3580/fsws/dirlist

Param1=/c//labview data/arc_tandh_scissor_lift/&Param2=XML&Param3=-s

And the response returned does indeed contain size information for the files:

<?xml version="1.0" encoding="UTF-8"?>
<directory name="/c//labview data/arc_tandh_scissor_lift/">
<directory name="logs">
</directory>
<file name="system-states_data.ini" size="167928" />
<file name="housekeeping_state_data.ini" size="3261" />
<file name="adv-pid_control_data.ini" size="1855" />
<file name="rt_environment.ini" size="646" />
<file name="stepper_configuration.ini" size="494" />
<file name="scaling_and_filter_data.ini" size="8743" />
<file name="md5 file checksums.ini" size="582" />
</directory>

This leads to my questions:

1. In the "dirlist" "-a" option broken?
2. How can I, using this API, get the file creation/modification dates for the files in the remote directory?

[WNM · Accepted solution]

Never mind. I found the problem.  The "Remote Single Directory List.vi" included as part of the API example has a small bug in it.

The "-a" constant circled below in orange should really be "-a " (there needs to be a trailing space after the "a"). You can sort of see it behind the other constants.

After adding the missing space and re-running the VI, I can get this information from the remote directory:

<?xml version="1.0" encoding="UTF-8"?>
<directory name="/c//labview data/arc_tandh_scissor_lift/" modtime="20130617100542">
<directory name="logs" modtime="20130520161247">
</directory>
<file name="system-states_data.ini" size="167928" modtime="20130617100542" />
<file name="housekeeping_state_data.ini" size="3261" modtime="20130617100542" />
<file name="adv-pid_control_data.ini" size="1855" modtime="20130617100542" />
<file name="rt_environment.ini" size="646" modtime="20130617100542" />
<file name="stepper_configuration.ini" size="494" modtime="20130617100542" />
<file name="scaling_and_filter_data.ini" size="8743" modtime="20130617100542" />
<file name="md5 file checksums.ini" size="582" modtime="20130617100542" />
</directory>

[WNM]

FWIW, I have found another flaw in the API example (found here: http://zone.ni.com/devzone/cda/epd/p/id/6466 ).

I am submitting my findings as "Reader Comments" to that web page but since I have no evidence that anyone is listening to them, much less fixing the example, I'm also going to report them here so that they will not get lost.

The subVI "Upload Single File.vi" is missing a call to the "AddHeader.vi" to setup the HTTP POST encoding method (= multipart/form-data). The Upload File vi seems to still work without this call if it is the first VI called after the handle is opened, but if other requests are made using the handle that use other methods first, then the POST vi returns an error when the "Upload Single File.vi" is later called.  All of the other subVIs in this API example do make use of the "AddHeader.vi" to setup their POST call.  The "Upload Single File.vi" should too.