OpenBSD not supported

[anoduck]

Describe the bug
Installed without a hitch using both pipx and then eventually standard pip3. Went to perform the linking of the account, and then received the error of platform not supported. Which usually means, it is missing a reference in the code.

Traceback (most recent call last):
  File "/usr/local/bin/maestral", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/maestral/cli/common.py", line 102, in wrapper
    proxy = ctx.with_resource(MaestralProxy(config_name, fallback=fallback))
  File "/usr/local/lib/python3.9/site-packages/maestral/daemon.py", line 649, in __init__
    if is_running(config_name):
  File "/usr/local/lib/python3.9/site-packages/maestral/daemon.py", line 336, in is_running
    return maestral_lock(config_name).locked()
  File "/usr/local/lib/python3.9/site-packages/maestral/daemon.py", line 291, in maestral_lock
    path = get_runtime_path("maestral")
  File "/usr/local/lib/python3.9/site-packages/maestral/utils/appdirs.py", line 206, in get_runtime_path
    raise RuntimeError("Platform not supported")
RuntimeError: Platform not supported

To Reproduce
Highly probable the error occurred due to missing a reference of OpenBSD as a platform option. So, to reproduce, attempt to install and run inside OpenBSD.

Expected behaviour
There is no reason this program, especially the cli, should not be able to run on OpenBSD. The official dropbox client does not run on OpenBSD, so maestral is needed.

System:

• Maestral version: 1.6.3
• Python version: 3.9.13
• OS: OpenBSD SnapShot CURRENT
• Desktop environment: i3
• PyQt version (for Linux GUI): 5.15.6

Additional context
I tried twice to get the gui installed, and maestral never recognized the gui packages were installed.

[samschott]

OpenBSD is indeed not currently supported. There is an open PR #681 which adds pro-forma support for multiple BSDs, however there are currently still a number of sync issues related to monitoring file system events through kqueue. In particular, there are still issues around the treatment of symlinks and possible errors to handle on startup.

[anoduck]

OpenBSD is indeed not currently supported. There is an open PR #681 which adds pro-forma support for multiple BSDs, however there are currently still a number of sync issues related to monitoring file system events through kqueue. In particular, there are still issues around the treatment of symlinks and possible errors to handle on startup.

Well, poop... although, this does explain why there is no "full-fledged" dropbox client available for OpenBSD. I have been looking for one for over a decade. Rclone works, but as you know, is not nearly the same thing.

Although there have been some revisions to kqueue made recently in release 7.1, I wouldn't know where to start.

Not sure whether you want to close this issue out, or leave it open as a feature request. Regardless, the choice is yours.

[samschott]

Yeah, the core issue with kqueue is that it monitors individual files only and requires a separate "watch" for each file. This makes it possible to watch existing files for changes or deletions but does not allow catching the creation of new files.

Therefore, any library which uses kqueue to watch for file system changes will need to do periodic scans of the entire watched hierarchy to find newly created files and add watches for them. This has multiple issues:

1. Slow performance for large folders.
2. Larger memory usage: We need to keep track of as many watches as there are files instead of consuming a single stream.
3. Custom scanning needs careful handling race conditions, symlinks, etc. It requires more attention to detail.

Those issues, together with the low market share of BSDs for end-user devices, explains why there is little motivation to support real time syncing with kqueue.

[anoduck]

Wow, I am sincerely thankful for the explanation. I understand now, and it makes sense. Watching every file in a particular region of the file system would create quite a considerable amount of subprocesses, and consume a lot of system resources. We both can admit, OpenBSD isn't really known for it's blazing fast processing speed, either. I can see why this would be a dealbreaker, and a pain to develop around.

Again, thanks for the explanation. I learned something. If it is OK, I am going to close this one out.