SeaDrive 3.0.24 macOS: seafile://openfile does not open files or folders; OpenLocalHelper method lookup error

Summary

On macOS, SeaDrive 3.0.24 receives seafile://openfile URLs and logs the correct repository ID and decoded path, but neither the requested document nor a requested folder opens. Warm-client attempts log a Qt method lookup error:

QMetaObject::invokeMethod: No such method OpenLocalHelper::1openLocalFile(const QUrl&)(QUrl)

The same server's open-locally workflow works on Windows (user-reported). This report concerns the macOS client.

Environment

• SeaDrive for macOS: 3.0.24
• macOS: 26.5.2 (25F84)
• Mac architecture: Apple Silicon
• SeaDrive GUI and SeaDrive File Provider are running
• macOS LaunchServices registers SeaDrive for the seafile: URL scheme
• codesign --verify --deep --strict /Applications/SeaDrive.app succeeds when run outside the diagnostic sandbox

Steps to reproduce

1. Configure SeaDrive with a server/account and a library containing a known file and an ASCII-only folder, for example /2026.

2. Start SeaDrive and let the account and File Provider initialize.

3. Open a URL targeting the existing folder, replacing REPO_UUID with the library UUID:

   bash复制

   open 'seafile://openfile?repo_id=REPO_UUID&path=%2F2026'

4. Also test an openfile URL targeting an existing DOCX in that library, with the library-relative path percent-encoded.

5. Inspect seadrive-gui.log and the visible application/Finder state.

Expected behavior

The folder opens in Finder, or the document opens in its associated local application.

Actual behavior

• macOS open returns exit status 0.
• SeaDrive receives the URL and logs the expected repository ID and decoded path.
• No document application or Finder folder opens in either test.
• The Qt method lookup error above appears on each warm-client test.
• Both an ASCII-only folder path and a document path containing Unicode characters fail. The Unicode path is decoded correctly in the log, so this does not appear limited to non-ASCII path decoding.

Relevant log excerpt (private identifiers replaced)

QMetaObject::invokeMethod: No such method OpenLocalHelper::1openLocalFile(const QUrl&)(QUrl)
[FileOpen] trying to open seafile://openfile?repo_id=REPO_UUID&path=%2F2026
get file repo id is REPO_UUID, email is , path is /2026

The example intentionally preserves the empty email field: the tested URLs contain repo_id and path, but no email parameter.

Additional diagnostics

• The behavior persists when testing with an already-running, initialized client, rather than only during cold start.
• Earlier post-upgrade tests had transient RPC broken-pipe/connection-refused errors. In the latest retest, the background RPC server had started and those errors no longer appeared; opening still failed with the method lookup error shown above.
• The GUI also logs a repeated PAC auto-discovery warning: Execution of PAC script at "http://wpad/wpad.dat" failed ... NSURLErrorDomain error -1003. Its relevance is unknown.
• The method lookup error is a correlated diagnostic observation, not a confirmed root cause. Could you confirm whether this URL format is supported by the macOS 3.0.24 client and investigate the local-open dispatch path?

Server addresses, account identifiers, real repository UUIDs, and private document paths have been omitted.