Go-ipfs: ipfs files cp <symlink> show "Error: symlinks not yet supported"

Created on 29 Jul 2018  路  10Comments  路  Source: ipfs/go-ipfs

Version information:

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

Type:

Bug(s)

Description:

  • mkdir -p builds/20180410T010424Z
  • ipfs add --nocopy --raw-leaves --local -r builds
    added QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn builds/20180410T010424Z
    added QmVkg29SP2ZCc24HAcSCjCUd1gfP4u32EPsyNoo5nvr2aY builds
  • ipfs files cp /ipfs/QmVkg29SP2ZCc24HAcSCjCUd1gfP4u32EPsyNoo5nvr2aY /builds
  • ln -s 20180410T010424Z builds/latest
  • ls -lh builds
    total 4.0K
    drwxr-xr-x 2 distfiles distfiles 4.0K Jul 28 23:03 20180410T010424Z
    lrwxrwxrwx 1 distfiles distfiles 16 Jul 28 23:03 latest -> 20180410T010424Z
  • ipfs add --nocopy --raw-leaves --local builds/latest
    added QmVhYBuGh6vKyQY3kP4ZH6m9jFvfzjCShs95pG6M9LUvc3 latest
    0 B / ? [---------------------------------------------------------------------------------------------------------------------------------------------=]
  • ipfs files cp /ipfs/QmVhYBuGh6vKyQY3kP4ZH6m9jFvfzjCShs95pG6M9LUvc3 /builds/latest
    Error: symlinks not yet supported
    _Note that we get an error message here ...._
  • ipfs files ls /builds
    latest
    20180410T010424Z
    _But here we can see that it was still added seemingly without issues_
  • ipfs files stat /builds
    QmYde2c7rdNfPXwJcHKwfvfu4tLYa5fuAFg4kbtSHfzPaF
    Size: 0
    CumulativeSize: 152
    ChildBlocks: 2
    Type: directory
  • ipfs files ls /builds/20180410T010424Z
  • ipfs files stat /builds/20180410T010424Z
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
    Size: 0
    CumulativeSize: 4
    ChildBlocks: 0
    Type: directory
  • ipfs files ls /builds/latest
    latest
  • ipfs files stat /builds/latest
    Error: unrecognized node type: Symlink

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.

kinbug neecommunity-input

All 10 comments

@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

https://github.com/ipfs/go-ipfs/blob/987fef12668f58dfdc5ca115fe87f5255222f455/core/commands/files.go#L231-L239

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?

Was this page helpful?
0 / 5 - 0 ratings