Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

mfs file type should return same type #2948

Closed
bluelovers opened this issue Mar 25, 2020 · 2 comments
Closed

mfs file type should return same type #2948

bluelovers opened this issue Mar 25, 2020 · 2 comments

Comments

@bluelovers
Copy link
Contributor

bluelovers commented Mar 25, 2020 •
edited
Loading

from stat is string
from ls is number

this will easy make bug happen when we not check real return value
@achingbrain
Copy link
Member

The spec docs say the type returned from ipfs.files.ls should be file or directory so changing this makes sense.

Would you like to create a PR for this that changes it to use strings everywhere? The HTTP API should remain unchanged but we can translate the types in core & the client.

You'll most likely have to change the interface tests too. Please make sure HAMT sharded directories are handled correctly.

@achingbrain achingbrain mentioned this issue Aug 15, 2020
Closed
@achingbrain achingbrain mentioned this issue Oct 27, 2020
Merged
achingbrain added a commit that referenced this issue Oct 27, 2020
@achingbrain @gcohler
fix: files ls should return string (#3352)
16ecc74 
Supersedes #3345 #2939
Fixes #3330 #2948

BREAKING CHANGE: types returned by `ipfs.files.ls` are now strings, in line with the docs but different to previous behaviour

Co-authored-by: Geoffrey Cohler <g.cohler@computer.org>
@achingbrain
Copy link
Member

Fixed in #3352

SgtPooki referenced this issue in ipfs/js-kubo-rpc-client Aug 18, 2022
@achingbrain @gcohler
fix: files ls should return string (#3352)
a6898ac 
Supersedes #3345 #2939
Fixes #3330 #2948

BREAKING CHANGE: types returned by `ipfs.files.ls` are now strings, in line with the docs but different to previous behaviour

Co-authored-by: Geoffrey Cohler <g.cohler@computer.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bluelovers @achingbrain