-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MFS directory listings with l: true
changes the file list order
#5181
Comments
It wouldn't seem so, a the function that lists entries ( |
Yeah, that sort should probably be removed and turned into an option (applied at a higher layer). |
Ok, I'll check if that sort can be removed without upsetting the current tests and add is as an option (independent of the |
So, while working on #5219 I remembered that the entries are already sorted at the DAG link level, I actually couldn't get an output from
@achingbrain Could you provide me an example of that? |
Oh, yes, you posted that when you submitted the issue, sorry, I'm not
familiar with that repo, I meant if you have a `go-ipfs` command example,
e.g.,
```
ipfs add
ipfs files cp /ipfs/<hash> /b
ipfs files cp /ipfs/<hash> /a
ipfs files ls /
# They appear in order
ipfs files ls / -l
# And now they don't
```
|
I'm suspecting that I'm confusing the JS |
Note: They're only sorted for non-sharded directories. |
|
Previously we'd get files in different orders between `files.ls()` and `files.ls({long: true})` due to a bug in `go-ipfs` (see ipfs/kubo#5181) Since this has been resolved we can now expect consistent ordering.
Previously we had to do the extra sort due to ipfs/kubo#5181 Now that's been resolved & released we can remove it, yay! License: MIT Signed-off-by: achingbrain <[email protected]>
Previously we'd get files in different orders between `files.ls()` and `files.ls({long: true})` due to a bug in `go-ipfs` (see ipfs/kubo#5181) Since this has been resolved we can now expect consistent ordering.
It seems that the order of directory contents returned from
ipfs.files.ls
api invocations changes if you passl: true
orl: false
.Compare (these tests have not previously only run against go-ipfs as there's been no mfs implementation in js-ipfs):
https://github.com/ipfs/interface-ipfs-core/blob/master/js/src/files/ls.js#L54-L61
vs
https://github.com/ipfs/interface-ipfs-core/blob/master/js/src/files/ls.js#L74-L92
Is this desired behaviour? Only we'll have to implement it in js-land as well if so.
The text was updated successfully, but these errors were encountered: