Documentation for file-get-fingrprint indicates it has a single member in the response, 'fingerprint' of type fingerprint-info, but the response is nested an extra level:
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE netapp SYSTEM '/na_admin/netapp_filer.dtd'>
<netapp version='1.1' xmlns='http://www.netapp.com/filer/admin'>
<results status="passed">
<fingerprint>
<fingerprint-info>
<fingerprint-algorithm>md5</fingerprint-algorithm>
<fingerprint-start-time>1333312676</fingerprint-start-time>
<formatted-fingerprint-start-time>Sun Apr 1 20:37:56 GMT 2012</formatted-fingerprint-start-time>
<fingerprint-scope>data_only</fingerprint-scope>
<fingerprint-version>1</fingerprint-version>
[..snip..]
</fingerprint-info>
</fingerprint>
</results>
</netapp>
It would appear that the intent was for the return to be 'fingerprint fingerprint-info[]', to traverse with child_get( 'fingerprint' )->children_get. (Perhaps this was in anticipation of future support to collect fingerprints for an entire directory[1]?)
...contrast to system-get-info, which has a nearly identical response structure ('system-info system-info') in documentation:
<netapp version='1.1' xmlns='http://www.netapp.com/filer/admin'>
<results status="passed">
<system-info>
<system-name>toaster</system-name>
<system-id>01111111</system-id>
[...]
</system-info>
</results>
</netapp>
[1] Though wouldn't that be the reason for metadata-files being an array? In its present form, I can't see where metadata-files would ever have more than a single member.
