Private shared folders in inconsistent state

[qirtaiba]

I have a private shared keybase filesystem folder with another user. At some point I shared some folders containing some large files with them which didn't transfer to their side properly, so I deleted everything at my side, apparently successfully because I no longer see them. But on their side, the folders still appear and can't be deleted (will update this issue with the exact error message shortly). Conversely, when the other side adds new files to the shared folder, now I don't see them. I'm assuming that this is because it's now in an inconsistent state and the two users have fallen out of sync so that they can't see each others' changes.

How do we hit the reset button and get the shared folder back to a consistent (empty is fine) state? I'm assuming simply uninstalling won't do it (and anyway, there are no uninstallation instructions).

[strib]

Hi @qirtaiba -- urg, that sounds rough. I would really like to see logs from each side -- running keybase log send and posting the IDs here would be great.

It's possible one of you is stuck, presumably due to a bug, in a "conflict resolution" state (see https://keybase.io/docs/kbfs/understanding_kbfs), where that device only sees local updates and has stopped syncing with the servers until conflicts are resolved. I'll be able to know for sure once I see the logs. You can also do cat /keybase/private/yourname,theirname/.kbfs_status (assuming you're on Linux or OS X) to check that for yourself -- look for "Staged": true in the output.

We can certainly reset the folder for you if the problem is unsolvable, but if you're not in a hurry I'd like to investigate it a little more.

[qirtaiba]

Thanks for your help. However I'd like to view the logs first because, since it's a private folder, there's personal information involved and I want to know what kind of metadata I'm sending over. Is there a way for me to vet the logs for private information? At least on my side, I'm seeing "Staged: false" (haven't checked the other side yet).

[strib]

Totally fair. Unfortunately we don't have a way to scrub the logs of metadata yet, sorry. It's on our (very long) TODO list. Besides data we can already figure out from our servers (like who you're sharing with), the logs would show us file names and sizes.

It's understandable if you don't want to share them -- in that case, we should find out the status of the other side. If it has staged == true, we can try to run some commands to force it back into unstaged mode. If we can't figure it out without the logs, I'll ask for your signed permission to just go ahead and reset the folder.

[qirtaiba]

Yes it has staged=true:

cat /keybase/private/terminus,suneva/.kbfs_status {   "Staged": true,   "HeadWriter": "suneva",   "DiskUsage": 121213117,   "RekeyPending": false,   "FolderID": "2a91b19fcf79e262eec2d3107a56fd16",   "DirtyPaths": null,   "Unmerged": null,   "Merged": null }

[qirtaiba]

and you're welcome to just reset the folder.

[strib]

Oops, sorry, this fell off my radar. Strange that it's in staging when Unmerged and Merged are both null. Logs from that device would be nice, but barring that he/she can try echo 1 > /keybase/private/terminus,suneva/.kbfs_unstage to attempt to force it to leave the staged state.

We can reset the folder too, but professional curiosity compels me to recommend something better.

[qirtaiba]

Thanks. It didn't work. The first time I did it I got this error: -bash: /keybase/private/suneva,terminus/.kbfs_unstage: Interrupted system call Then I quit and restarted keybase and tried again and I got this error: -bash: echo: write error: Input/output error Then the third time I tried it didn't give an error, but staged=true remained. When I tried to open the folder I got a dialog with this error: Keybase: Read timeout in /keybase/private/suneva,terminus: The read operation took too long and failed. Also something else that you should know: there is an additional shared folder which has appeared on the staged system only, which looks like this: dc459374ec96bc9daf3be3258d35b219@uid,f7d181187f5bca7949524548d7599800@uid It can't be deleted.

[strib]

Hmm that weird folder makes me think whoever has it is or was running a very old version of kbfs. Can you tell me the KBFS version reported by keybase status?

For what it's worth, the usernames on that folder do not match the ones on the problem TLF. (You can check them with keybase id uid:<UID> for each <UID> in the TLF.

I will look into manually deleting the staged branch for the problem folder.

[strib]

Ok, we've deleted the "staged" branch for that folder. If you restart KBFS on the device that had staged=true, I hope everything will be back to normal.

[qirtaiba]

Thanks, it is back to normal in the sense that we're both seeing the same thing now, but we both transferred files to each other (214kb and 116Mb) and neither of them transferred fully to the other side, resulting in corruption when we try to open the other person's file.

Anyway, that's a separate issue I guess.

[strib]

Thanks, it is back to normal in the sense that we're both seeing the same thing now, but we both transferred files to each other (214kb and 116Mb) and neither of them transferred fully to the other side, resulting in corruption when we try to open the other person's file.

Yikes, that's definitely unexpected. Please open a new issue, ideally with logs if you can. Please at least include the KBFS versions reported by keybase status.