Internal links with special characters do not open on client when shell.open called from firefox browser

Seafile Client
1

When I create an internal link with a special character - e.g. Ö - in the path, copy/pasting the link to the webbrowser will make both seafile/seadrive error on the name.

[Screenshot scrubbed]

The external link works fine. I suppose this is a client only problem (windows client, linux server, both the latest releases.) Low hanging fruit perhaps :wink:

ADD: Here https://github.com/haiwen/seafile-client/blob/167aaa13f95d6203ec116fe3a84cd5bf88ed08c2/src/repo-service-helper.cpp#L25 this warning gets thrown.

Here the URL passed is already damaged - https://github.com/haiwen/seadrive-gui/blob/ebd31a51dabed0370c4f325129b10d3fcd353934/src/rpc/rpc-server.cpp#L61 - Obviously seadrive-gui receives it mangled already.

[Speculation scrubbed]

2

A bit of digging later, looking what the utf-8 encoded applet.log contains:

[06/27/23 13:53:16][rpc server] seafile://openfile/?repo_id=...&path=/%EF%BF%BDBV.pdf

which translates to /�BV in utf-8 - note the REPLACEMENT CHARACTER - The internal link though reads

seafile://openfile?repo_id=....&path=/%C3%96BV.pdf

which translates to /ÖBV in utf-8. So the path string must have been corrupted even earlier in code.

3

Bummer, these multibyte characters are no problem on the linux command line

seafile-applet -f 'seafile://openfile?repo_id=....&path=/%C3%96BV.pdf' will open just fine!

Will try later today on W10 command prompt. Perhaps get more insight, who puts the “�” U+FFFD Replacement Character Unicode Character there.

One more bummer, these characters are no problem on the windows command line:

seadrive-gui.exe -f "seafile://openfile?repo_id=....&path=/%C3%96BV.pdf" will open just as fine!

So, could it be the firefox browser? Indeed, pasting the link in google-chrome and files with special chars open in seadrive. But it is not that easy! Using a small batch file to process the handler, in sysinternals process explorer I see, that firefox passes the url correctly. The replacement char must be added by another agent.

4

I created a small python script to handle seafile:// URLs:

# Launch seadrive from internal link
 
import sys
import subprocess
import os

n = len(sys.argv)
print("\nArguments passed:", end = " ")
for i in range(0, n):
    print(sys.argv[i], end = " ")
print("\n")

subprocess.run(['C:\\Program Files\\SeaDrive\\bin\\seadrive-gui.exe', '-f', sys.argv[1]])

os.system("pause")

When instructing firefox to use that to handle seafile:// URLs they open just fine, no matter what special chars!

UPDATE: Using another sysinternals tool called procmon gives additionial insight:

When calling seadrive-gui from google-chrome or from my small helper app, the commandline argument to seadrive-gui stays all ascii. When seadrive-gui gets called from firefox directly, the %C3%96 escape sequence gets decoded to ANSI letter “Ö”. I suspect, that this will trip the utf-8 decoder to replace that with �. Curiously, my helper app receives the argument as ascii from firefox.

Could there be a middle-man mangling strings?