hyperdrive status reporting fuse unavailable after updating daemon
Describe the bug
After updating to [email protected], fuse had been setup with the previous version, hyperdrive status is reporting
The Hyperdrive daemon is running:
API Version: 0
Daemon Version: 1.13.12
Client Version: 1.15.1
Schema Version: 1.10.0
Hyperdrive Version: 10.11.0
Fuse Native Version: 2.2.2
Hyperdrive Fuse Version: 1.2.15
Holepunchable: true
Remote Address: *ip address removed*
Fuse Available: false
Fuse Configured: false
However, fuse appears to be working - in that there is contents in ~/Hyperdrive/Network when the daemon is running. Although ~/Hyperdrive/Network/<drive-key> don't appear in ls until they accessed (e.g. cd <drive-key>).
I also notice that hyperdrive status fails with Error: EPERM: operation not permitted, when in a
To Reproduce Steps to reproduce the behavior.
Expected Behavior I expect status to indicate Fuse are available and configured after upgrading, both having been true before the upgrade.
** OS ** macOS 10.15.4
** Node version ** 12.16.3
** Was the daemon installed from NPM or bundled with Beaker? ** Running the deomon, installed using NPM, from the command line. Though I do have Beaker 1.0 Beta pre-release 2 installed.
Add any other context about the problem here.
From ~/.hyperdrive/log.json, am seeing a lot of the following error line,
{"level":50,"time":1590054689872,"pid":1141,"hostname":"paul.local","name":"hyperdrive","component":"fuse-manager","msg":"by-key handler error","v":1}
I half expect this is all connected with a Beaker issue I have with one drive not openning - https://github.com/beakerbrowser/beaker/issues/1639
Hey @paul90 thanks for this. There are a few separate issues in here so I'll try to pick them apart.
For the FUSE one, In 1.13.12 we updated fuse-setup so that you can run it at any time, including when the daemon is running. Looks like I missed a spot when it comes to setting those available/configured flags. Think it's just a reporting issue, not a logic issue inside the FUSE handling (because the rest of it seems to work for you).
The thing you're describing about the Network folder not enumerating keys is intentional, since the key space is infinite :) We create those directories for the last N keys you've accessed in order to prevent bugs with the OSX Finder.
As for the EPERM bug, can you elaborate a bit more? Any tips for reproducing this?
Thanks @andrewosh
For the EPRM bug, using hyperdrive status while in ~/Hyperdrive/Network/<drive-key>.