説明
ipfs get does not handle paths with platform specific separators in them gracefully.
Consider the structure
test (QmSqqKkPViWCn5c6LShAqved78NtYr5okY8gN2frkNzJ9E)
|-- Directory with slash\ in it
| |-- Filename with slash\ in it
| `-- Regular filename
`-- Directory without slash in it
|-- Filename with slash\ in it
`-- Regular filename
geting this on a system that uses \ as a path separator results in an error. Here's an example on Windows with \.
[Note: github doesn't like this image for some reason, hosting via ipfs]
@whyrusleeping mentioned this in PR https://github.com/ipfs/go-ipfs/pull/1933#issuecomment-158579349 for add but it shouldn't be possible to add an invalid path on your platform so it was a non issue there, that's not the case for get though.
To handle this there would need to be some table of restricted symbols for various file systems/schemes/whatever, said symbols would need to be replaced with some other valid symbol. Maybe try to use the given path/name and fallback to filtering on errors like these? This would tamper with the validity of the objects you're getting, they wouldn't add up to the same hash but since the hash already exists and you already have it, pinning it directly should make this a non-issue.
Outside of Windows restricting \ I'm not sure what else if anything is effected.
A way to workaround this is to circumvent get by using the gateway and external tools that do this conversion, for example using wget
wget -r http://127.0.0.1:8080/ipfs/QmSqqKkPViWCn5c6LShAqved78NtYr5okY8gN2frkNzJ9E
This will percent encode the offending slash.
Paging: @rht