Open salshyn opened 8 years ago
CC @zanderz @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:
Currently not on Windows for symlinks located on kbfs (not just pointing there):
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
:
@salshyn, thanks. will investigate this.
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.
@taruti, Could you please give me an approximate fix date for this issue?
@salshyn This appears to be caused by https://github.com/dokan-dev/dokany/issues/293
Dokan is the filesystem driver we use on Windows.
@salshyn we have a fix in https://github.com/keybase/kbfs/pull/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:
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
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:
After that I make a symbolic link like this:
The symbolic link is created but I can't access it. When trying to
cd
intoC:\Users\salshyn\Downloads\Test\countries
I get an error saying: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!