go-ipfs version: 0.4.15-
Repo version: 6
System version: amd64/linux
Golang version: go1.10.2
Latest stable in Gentoo
Also recreated with
go-ipfs version: 0.4.17-
Repo version: 7
System version: amd64/linux
Golang version: go1.10.3
Bug(s)
Script found at zb2rhobUBn2cxPp3azT6saXfma7bzPAVyinrpnEszhkFKWCQs
From the above it seems that Error: symlinks not yet supported Should be removed when used with ipfs files cp since it does what it is supposed to? Or it should be changed to a Warning.
When doing ipfs files stat on a symlink we get Error: unrecognized node type: Symlink - Even if a node type is unrecognized it should still output the same stats, especially the hash.
So my suggestion is to move the error to after output, especially relevant if --hash was used.
@schomatis think you can figure out what's happening here? It looks MFS/dag related.
Yes, on it.
The problem happens when the file is being opened to be flushed (after it has been created).
We already need to rewrite the entire flush logic (https://github.com/ipfs/go-mfs/issues/3) but in the meanwhile I'll submit a PR wrapping the flush error as suggested by @NiKiZe so the user knows where is this coming from and close this issue.
So with this version when running
ipfs files stat /builds/latest
There will be no error?
Or at least running
ipfs files stat --hash /builds/latest
Would give the hash correctly?
Since building IPFS makes me kind of uneasy, could someone run my above script on the fixed IPFS version and post the output?
No, that wasn't fixed, I got hanged with the first error.
We could just add another case in the command itself, but I rather solve this in go-unixfs instead of hard-coding more attributes here
https://github.com/ipfs/go-ipfs/blob/987fef12668f58dfdc5ca115fe87f5255222f455/core/commands/files.go#L231-L239
@overbool What do you think? This could be resolved in a similar way to the IsDir feature, but creating a more general function that would classify the types. Thinking about this it seems more a responsibility of the MFS layer than of UnixFS to make this type of classification. I'll need to give this some more thought. I need to finish the documentation of the UnixFS protobuf types (https://github.com/ipfs/go-ipfs/pull/5153).
@schomatis I think we could add a function like TypeString():
func (n *FSNode) TypeString() string {
switch n.format.GetType() {
case pb.Data_Directory, pb.Data_HAMTShard:
return "directory"
default:
return "file"
}
}
just like you comment in https://github.com/ipfs/go-ipfs/issues/5217, we could replace FromBytes with FSNodeFromBytes, and then modify
to the follow code
case *dag.ProtoNode:
d, err := ft.FSNodeFromBytes(n.Data())
if err != nil {
return nil, err
}
ndType := d.TypeString()
This looks like it might already be done?