Creating and deleting shared private folders in Keybase filesystem under Windows
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 9.2k
- Forks
- 1.3k
- Avg merge
- 12h 58m
- Merged PRs (30d)
- 56
Description
First of all, I already had a "K:" drive in use, but the installation did not show any warning or error. My former drive was usable (it was also a dokan-powered cripto unit) but I coultn't find the private or public folder.
After unmounting the former drive and changing the letter, both folders under keybase were accesible without restarting at all. This is the second time a software I install "forces" me a fixed drive letter (both cases I already had that drive in use) and I find it somewhat annoying, since moving the former drive usually requires me more effort (software installation broken, image & music databases broken, etc.). Would it be possible to ask for a drive letter upon installation?
Moving into the bug itself: As I explained I'm using the Windows client, so commands to create and remove folders vary a little (md/rd instead of mkdir/rmdir on top of the different folder structure):
md k:\private\someuser
rd k:\private\someuser
That isn't a problem in itself (except most documentation is for *NIX), but IT IS a problem when trying to create or delete a "shared" folder:
md k:\private\nuttyx,otheruser
will not create a "shared" folder for me and otheruser, but instead will "create" k:\private\nuttyx and another folder in my current path called "otheruser". If that path is k:\private it will raise an error in Keybase since you are not allowed to access the private folder of another user.
That is really a problem with Windows' syntax (correct syntax is with quotes: md "K:\private\nuttyx,otheruser"), but after creating a "shared" folder I tried to remove it and forgot again the quotes and deleted my own folder instead. After that, I recreated my folder via explorer.exe, but in the Keybase GUI my own folder (which I could see under K:\private) was not longer present.
I deleted it again and tried to re-create it via Keybase GUI -> New private folder, but nothing happened.
Then the GUI got messed up:

The left menu stopped working and changing between public and private folder only changed background color from blue to white.
Also, my private view would no longer show my private folder, but the shared one even when both folders were present at k:\private in explorer.exe.
Restarting the system would fix the broken GUI, but my private folder wouldn't show up again in the GUI until I deleted and created it via rd and md in the keybase console. Also, deleting via explorer.exe the shared folder would not affect the GUI (it showed it as it was still present)
To summarize:
rd and md commands seem to work just fine to fix what you see in the Keybase GUI (until you break the GUI itself), but you might need to delete and recreate the folder.
It would be nice to make the comment about the need for quotes for md/rd commands for shared folders under Windows.
Keybase GUI seems to break when I try to create a new private folder or open the public folder.
Keybase GUI Version: 1.0.16-20160713110836+a1c00b3
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Windows client flows described for creating and deleting private and shared folders with md, rd, Explorer, and the Keybase GUI. Compare the filesystem state with the GUI after each operation, including public/private navigation and refresh behavior. Done means the reported GUI breakage and stale folder views are resolved, with the Windows quoting requirement documented if documentation remains in scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100