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

[NiKiZe]

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.

[Stebalien]

@schomatis think you can figure out what's happening here? It looks MFS/dag related.

[schomatis]

Yes, on it.

[schomatis]

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 (ipfs/go-mfs#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.

[NiKiZe]

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?

[schomatis]

No, that wasn't fixed, I got hanged with the first error.

[schomatis]

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

[schomatis]

@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 (#5153).

[overbool]

@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"
	}
}

[overbool]

just like you comment in #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()

[hoffmabc]

This looks like it might already be done?