Bug: Full path in symlink on windows

[ivan386]

Version information:

go-ipfs version: 0.4.16-
Repo version: 7
System version: amd64/windows
Golang version: go1.10.2

Type: Bug

Description:

>ipfs add -r "D:\symlink_test"
added QmbqVqMVvaDi96Wqv4uKWXhTnp6dVGrMFYXneCms5kwpQt symlink_test/symlink_to_test
 0 B / ? [-------------------------------------------------------------------------------------------
added QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn symlink_test/test
 0 B / ? [-------------------------------------------------------------------------------------------
added QmaVcUhni47SSnsVqMw53xW1Fkq5BrPQCVCHsc8Bdg2ZtJ symlink_test
 0 B / ? [-------------------------------------------------------------------------------------------

>ipfs block get QmbqVqMVvaDi96Wqv4uKWXhTnp6dVGrMFYXneCms5kwpQt

���D:\symlink_test\test

[magik6k]

cc @djdv

[djdv]

@ivan386
Can you give more details on what you're adding and what is expected here?
I think these are related
#4750
ipfs/go-ipfs-cmds#96

[ivan386]

On drive d: create 2 directory.

1. symlink_test
   md symlink_test
2. symlink_test/test

cd symlink_test
md test

And make junction point to "test" as "symlink_to_test"
linkd symlink_to_test test

When add it to ipfs
ipfs add -r "D:\symlink_test"
It created 3 blocks.

1. added QmbqVqMVvaDi96Wqv4uKWXhTnp6dVGrMFYXneCms5kwpQt symlink_test/symlink_to_test
   Symlink block
2. added QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn symlink_test/test
   Empty directory
3. added QmaVcUhni47SSnsVqMw53xW1Fkq5BrPQCVCHsc8Bdg2ZtJ symlink_test
   Root directory

When i look in content of symlink block i see full path in it.

>ipfs block get QmbqVqMVvaDi96Wqv4uKWXhTnp6dVGrMFYXneCms5kwpQt

���D:\symlink_test\test

There must be relative path. And maybe in unix style.
test
or
./test

[djdv]

@ivan386
I believe this is the intended behaviour. Junctions can only be absolute paths, and you are adding the junction, as a link (who's target is absolute). For your case here, you would instead create a symbolic link, which can be relative.

md symlink_test
cd symlink_test
md test
mklink /D symlink_test test
ipfs add -r "D:\symlink_test"

For me, the result:

ipfs block get QmdaH1brf4LgVBVerDETfYu1Unsez9yeBxDvktnsBku5S7

���test

Full wrapped hash: /ipfs/Qmes4dzy4aAH6HhiqTq1HaJkFLFVEDybCVZyQjEEaGFDuJ

[ivan386]

On Windows XP available only junction points. In both cases ipfs make symlink block. Difference only in path.

Need to convert full path to relative when add junction point to ipfs.

Full path is useless on gateway and on other file system. If on target system need full path than it can be build from relative.

[djdv]

Full path is useless ... on other file system

I would disagree with this. I've seen people using the SUBST command to map development directories as drive letters for consistent absolute paths, across machines/groups.
i.e.
subst D: "C:\Users\dd\dev-env"
Typically to work around older platform restrictions such as this one (among others).

---

In any case though, I don't think anything can be done about this in our mainline branch.
We currently add junctions and symlinks on Windows as-is, since this is the likely intent of the user. A full replication of what is actually there, not a modification of it.

In addition, the problems are that, we don't know when the user would want to force junctions to be treated as relative paths, and more importantly, XP users would not be able to unpack the created hashes, as junctions must be absolute. We'd not know which drive letter to use, or what type of links to use while unpacking, without adding flags to add and get, as well as a platform check.
For example:
add --relative-junctions and get --junction-prefix=D:\
+
if XP { linkType=junction }

It should be possible, but I don't think we'll implement that in our branch, since it's a special case which modifies input and output data.

The changes to tar-utils should make it easy for developers to add their own link handling method on get, like this https://github.com/djdv/go-ipfs/blob/4d874f723d3d8a05d40606642906de427fec6e42/core/commands/get.go#L264-L269

Unofficially, you may be interested in this:
http://schinagl.priv.at/nt/ln/ln.html#symboliclinksforwindowsxp
(/ipfs/QmeAwgebTKn6zqafBaCm79wRG9Tk7sTLyGkrsUvk2F26KJ)
to work around the limitations of XP.

[djdv]

Closing this as this is standard/intended behavior of NT "junctions", which are not semantically "symlinks".