You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On systems like Linux, we're expecting $XDG_STATE_HOME to be set up and usable. If it's not, the default values for the daemon's socket is likely to fail with a message like this: daemon: could not listen on: /unix/home/user/.local/state/fs/server - mkdir /home/user/.local/state/fs: no such file or directory.
We should check for the existence of it first, and try to use it if it's there. And otherwise fall back to whatever common defaults exist.
I think the BSDs used to place these in /var/run, but we can probably just create our own thing in the home directory that get's cleaned up upon exit.
Long term, we shouldn't use Unix domain sockets as the defaults on systems that have better options.
I.e. name spaced sockets on Linux, named pipes on NT, etc.
This sidesteps dealing with the file system at all.
The text was updated successfully, but these errors were encountered:
On systems like Linux, we're expecting
$XDG_STATE_HOME
to be set up and usable. If it's not, the default values for the daemon's socket is likely to fail with a message like this:daemon: could not listen on: /unix/home/user/.local/state/fs/server - mkdir /home/user/.local/state/fs: no such file or directory
.We should check for the existence of it first, and try to use it if it's there. And otherwise fall back to whatever common defaults exist.
I think the BSDs used to place these in
/var/run
, but we can probably just create our own thing in the home directory that get's cleaned up upon exit.Long term, we shouldn't use Unix domain sockets as the defaults on systems that have better options.
I.e. name spaced sockets on Linux, named pipes on NT, etc.
This sidesteps dealing with the file system at all.
The text was updated successfully, but these errors were encountered: