Tags: p9c/kbfs
Tags
favorites: allow some non-true disable env var values Suggested by jzila. Issue: keybase#1862
cr: ignore `changeOriginal` call between two same pointers I've been unable to get good logs that reproduce this issue, and it seems safe to just ignore the case where CR is trying to change an original between two identical pointers. This probably indicates something like the device putting an MD, but failing before it finds out that the put succeeds. Then later it tries to resolve the conflict against itself. In theory, we have other protections against this, and it would be nice to figure out why it's causing problems in this case, but it's probably best to paper over it for now and just give the user a smoother experience. It's possible that when the CR finally succeeds, it will end up with a bunch of conflict files, which might get the user's attention quickly and entice them to send logs soon (thus capturing the original source of the problem). Issue: KBFS-2946
stderrutils: build on android Tested on Android Termux. I don't know why this was like this before. ``` $ go env | grep GOOS GOOS="android" $ git push origin master Initializing Keybase... done. Syncing with Keybase... done. Counting and decrypting: 3 objects... done. Preparing and encrypting: (100.00%) 3/3 objects... done. Indexing hashes: (100.00%) 3/3 objects... done. Indexing CRCs: (100.00%) 3/3 objects... done. Indexing offsets: (100.00%) 3/3 objects... done. Syncing encrypted data to Keybase: (100.00%) 7.45/7.45 KB... done. To keybase://private/philips/foo 6c3a499..b226459 master -> master ```
prev_revisions: avoid panic when count is about to overflow jzila called it. Some user reported an issue where the count can reach 255. I can't repro it yet, but I suspect it has to do with removing revisions from the front of the list when running conflict resolution, and thereby letting the entries at the end of the list build up their count.
-
Aug 6, 2018 - 8BDF f056d29
- zip
- tar.gz
prev_revisions: avoid panic when count is about to overflow jzila called it. Some user reported an issue where the count can reach 255. I can't repro it yet, but I suspect it has to do with removing revisions from the front of the list when running conflict resolution, and thereby letting the entries at the end of the list build up their count.
prev_revisions: avoid panic when count is about to overflow jzila called it. Some user reported an issue where the count can reach 255. I can't repro it yet, but I suspect it has to do with removing revisions from the front of the list when running conflict resolution, and thereby letting the entries at the end of the list build up their count.
implement SimpleFSSuppressNotifications (keybase#1667) * implement SimpleFSSuppressNotifications * update vendor to pull in strib feedback * review feedback from strib * fix confusing paramter name as suggested by strib * update vendor to master
PreviousNext