[KBFS] Support for symbolic link to location underneath a Keybase TLF?

[salshyn]

Hello,

This is my environment:

Environment: Windows 10 Pro
Keybase: 1.0.15-20160503112215+243eebf

Creating a symbolic link outside Keybase that links to a location somewhere under a Keybase TLF seems to work OK in OSX but when I try an equivalent operation in Windows 10, it doesn't work. I have a Keybase path like this:

K:\private\salshyn\travel\countries\test.txt

After that I make a symbolic link like this:

mklink /D "C:\Users\salshyn\Downloads\Test" "K:\private\salshyn\travel"

The symbolic link is created but I can't access it. When trying to cd into C:\Users\salshyn\Downloads\Test\countries I get an error saying:

The system cannot find the path specified.

And through file explorer, double-clicking on the countries folder I get a dialog box that reads:

Location is not available. C:\Users\salshyn\Downloads\Test\countries is unavailable. If the location is on this PC, make sure the device or drive is connected or the disc is inserted, and then try again. If the location is on a network, maker sure you're connected to the network or Internet, and then try again. If the location still can't be found, it might have been moved or deleted.

Can someone let me know a) whether this kind of symbolic linking is supported and b) to the degree it is supported, should what works on OSX also work on Windows?

Thanks in advance!

[cjb]

CC @zanderz @taruti

[taruti]

Hi,

Windows requires you to be admin for creating symbolic links with mklink. Can you verify that you can create symbolic links inside C (e.g. C:\temp\foo ->
C:\temp\bar).

Symlinks from outside to kbfs (C->K) should work.

For links inside K: (that is e.g. K->K or K->C) currently there are the following limitations (these are not permanent):

Currently works on Windows:

• Following existing symlinks (created on *nix)
• Statting both symlinks and files/directories they are pointing to
• Derefencing symlinks and using the target object for open/read/write/readdir/...
• Everything for symlinks from outside to kbfs

Currently not on Windows for symlinks located on kbfs (not just pointing there):

• No mklink
• No explicit readlink

[salshyn]

Hi, @taruti,

1. I just verified that creating symbolic links is working with the scenario you specified (C:\temp\foo -> C:\temp\bar).

Command I used:
mklink /D "C:\temp\bar" "C:\temp\foo"

2. Symlinks from outside to kbfs (C->K) should work, but it's still not working.

Command I used:
mklink /D "C:\temp\bar" "K:\private\salshyn\temp\foo"

Here's the response when I try to access C:\temp\bar\insideFoo (Please note, that insideFoo is a folder inside K:\private\salshyn\temp\foo:

[taruti]

@salshyn, thanks. will investigate this.

[taruti]

Ok, I see the issue. After traversing the symlink windows thinks it is ok to use all caps filenames.

e.g. with C:\foo -> K:\private\user\bar and trying to access C:\foo\baz kbfsdokan is passed K:\private\user\bar\BAZ which obviously does not work.

Thanks for the bug report will work on solving this.

[salshyn]

@taruti,
Could you please give me an approximate fix date for this issue?

[taruti]

@salshyn This appears to be caused by dokan-dev/dokany#293

Dokan is the filesystem driver we use on Windows.

[taruti]

@salshyn we have a fix in keybase/kbfs#201 will take some time until that is in a release.

@Steve could you close this after we ship a release with that pull request?

From the commit:

Symlink destinations from outside KBFS to KBFS

Windows makes paths case insentive in symlink destination. KBFS has
support for this in the case that the case insensitive path is unique
and guessable.

To make this work make symlinks from outside KBFS to KBFS make it refer
to either the root of the drive or use PRIVATE or PUBLIC in the path
instead of private and public. This enables the case insentive path
resolving logic inside KBFS.

e.g.

C:
cd \tmp
mklink /D link1 K:\
mklink /D link2 K:\PRIVATE
mklink /D link3 K:\PRIVATE\user1,user2