You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 10, 2020. It is now read-only.
The IPFS documentation for 'ipfs files ls' CLI command (https://docs.ipfs.io/reference/api/cli/#ipfs-files-ls) lists the long listing option as using:
-l bool
The src/files/ls.js implementation expects -long as the parameter instead.
The documentation at https://github.com/ipfs/interface-js-ipfs-core/blob/master/SPEC/FILES.md#filesls shows using 'long' for the option. This is consistent with the implementation in the ls.js code. The HTTP post request created also uses 'long' as the option flag.
But the 'long' flag is not valid for current implementations of IPFS and is ignored. This results in the long listing never being returned.
I am using
ipfs-http-client version 40.1.0
ipfs version 0.4.22
on macOS 10.15.1
To test, I am using the following client code
const ipfsClient = require('ipfs-http-client');
const listImages = async callback => {
// connect to ipfs daemon API server
const ipfs = ipfsClient('http://localhost:5001');
const imageDir = await ipfs.files.ls('/dockerImages');
for await (const dir of imageDir) {
console.log(dir.name);
const files = await ipfs.files.ls('/dockerImages/'+dir.name, {long: true});
files.forEach ((file) => {
console.log('\t'+file.name);
console.log('\t'+file.hash)
});
}
};
listImages();
where I have files in my local IPFS node under /dockerImages
passing {long: true} as the option paramter to ipfs.files.ls will never return the long results.
To get things working locally, I changed line 22 in ls.js to
if (options.l != null) searchParams.set('l', options.l)
and passing the options parameter in the client code as
{l: true}
results with correctly returning Hash, Type, and Size values.
You could alternatively change the code in ls.js to accept long and the option name but translate it to 'l' before making the http request.
Thoughts on this?
The text was updated successfully, but these errors were encountered:
The IPFS documentation for 'ipfs files ls' CLI command (https://docs.ipfs.io/reference/api/cli/#ipfs-files-ls) lists the long listing option as using:
-l bool
The src/files/ls.js implementation expects -long as the parameter instead.
The documentation at https://github.com/ipfs/interface-js-ipfs-core/blob/master/SPEC/FILES.md#filesls shows using 'long' for the option. This is consistent with the implementation in the ls.js code. The HTTP post request created also uses 'long' as the option flag.
But the 'long' flag is not valid for current implementations of IPFS and is ignored. This results in the long listing never being returned.
using
$ curl "http://localhost:5001/api/v0/files/ls?arg=/&stream=true&long=true"
returns
{"Entries":[{"Name":"dockerImages","Type":0,"Size":0,"Hash":""}]}
using
$ curl "http://localhost:5001/api/v0/files/ls?arg=/&stream=true&l=true"
returns
{"Entries":[{"Name":"dockerImages","Type":1,"Size":0,"Hash":"QmZH8ouPv46gMjckBAcPz1Aa82td6kA95cEZ7G6vP6uWdy"}]}
I am using
ipfs-http-client version 40.1.0
ipfs version 0.4.22
on macOS 10.15.1
To test, I am using the following client code
const ipfsClient = require('ipfs-http-client');
const listImages = async callback => {
// connect to ipfs daemon API server
const ipfs = ipfsClient('http://localhost:5001');
};
listImages();
where I have files in my local IPFS node under /dockerImages
passing {long: true} as the option paramter to ipfs.files.ls will never return the long results.
To get things working locally, I changed line 22 in ls.js to
and passing the options parameter in the client code as
{l: true}
results with correctly returning Hash, Type, and Size values.
You could alternatively change the code in ls.js to accept long and the option name but translate it to 'l' before making the http request.
Thoughts on this?
The text was updated successfully, but these errors were encountered: