pyfuse3
pyfuse3 copied to clipboard
Various FreeBSD issues
There are a number of issues with pyfuse3 on FreeBSD right now.
Buildtime issues:
- In
src/pyfuse.pyx
, there'sdef syncfs(path)
function that callslibc_extra.syncfs()
, which is expected to be available inunistd.h
. However, there's no such function available on FreeBSD, and, in general, it appears to be Linux-only. - In
src/pyfuse3.pyx
, it's expected thatlinux/fs.h
containsRENAME_EXCHANGE
andRENAME_NOREPLACE
which's not the case on FreeBSD (there's no such header at all).
Runtime issues:
$ sudo python3 examples/tmpfs.py ~/fuse
Traceback (most recent call last):
File "examples/tmpfs.py", line 451, in <module>
trio.run(pyfuse3.main)
File "/usr/local/lib/python3.6/site-packages/trio-0.11.0-py3.6.egg/trio/_core/_run.py", line 1444, in run
raise runner.main_task_outcome.error
File "/usr/home/novel/code/pyfuse3/src/_pyfuse3.py", line 30, in wrapper
await fn(*args, **kwargs)
File "src/pyfuse3.pyx", line 732, in main
async with trio.open_nursery() as nursery:
File "/usr/local/lib/python3.6/site-packages/trio-0.11.0-py3.6.egg/trio/_core/_run.py", line 506, in __aexit__
raise combined_error_from_nursery
File "/usr/home/novel/code/pyfuse3/src/_pyfuse3.py", line 30, in wrapper
await fn(*args, **kwargs)
File "src/internal.pxi", line 229, in _session_loop
await _wait_fuse_readable()
File "src/internal.pxi", line 205, in _wait_fuse_readable
async with worker_data.read_lock:
File "src/internal.pxi", line 207, in pyfuse3._wait_fuse_readable
await trio.hazmat.wait_readable(session_fd)
File "/usr/local/lib/python3.6/site-packages/trio-0.11.0-py3.6.egg/trio/_core/_io_kqueue.py", line 131, in wait_readable
await self._wait_common(fd, select.KQ_FILTER_READ)
File "/usr/local/lib/python3.6/site-packages/trio-0.11.0-py3.6.egg/trio/_core/_io_kqueue.py", line 120, in _wait_common
self._kqueue.control([event], 0)
OSError: [Errno 19] Operation not supported by device
$
I'm yet to debug this traceback further.
Thanks for the report! I've never tried to use pyfuse with BSD at all, so you may into all sorts of issues. Happy to accept patches if they not too invasive though.
I have workarounds for the build time issues, but probably it doesn't make a lot of sense to send patches before I can get it working.
Right now I'm not sure how to approach this traceback though. WIll be good to at least figure out if that's pyfuse or trio issue first. Ideas are welcome.
I suspect the problem is that FreeBSD does not support polling on the fuse descriptor. So it's not an issue in one specific library, trio seems to be using kqueue for polling on FreeBSD, and pyfuse3 passes an fd to trio for which this isn't supported. Maybe trio could be changed to use a different polling primitive - or it may need kernel support.
I noticed that trio fails to poll even on files like /dev/random
or /dev/null
, while kqueue generally works fine with that: https://github.com/python-trio/trio/issues/1050
Also, when I try to run some pyfuse examples and it fails, it leaves the mount point:
$ mount|grep fuse
/dev/fuse on /usr/home/novel/fuse (fusefs, local, synchronous)
$
And I can run my C test program I included in the trio issue on /dev/fuse
:
$ ./a.out /dev/fuse
/dev/fuse ready to read
$
Are there any news for freebsd compatibility?
I am looking at pyfuse3 as a successor of unmaintained llfuse (which works on linux, freebsd, macOS, ...) but I need something with at least similar platform support.