1. Download attachment 182402 [details] from bug 150926; 2. Rename the filename from 'pystringtest.oxt' to, e.g., 'pystringtest (2).oxt'; 3. Try to install it (e.g., double-click the .oxt in the file manager to execute "soffice '/path/to/pystringtest (2).oxt'"). => installation would fail, with something like > (com.sun.star.uno.RuntimeException) { { Message = "<class 'FileNotFoundError'>: [Errno 2] No such file or directory: > 'C:\\\\Users\\\\mikek\\\\AppData\\\\Roaming\\\\LibreOffice\\\\4\\\\user\\\\uno_packages\\\\cache\\\\uno_packages\\\\lu233889xtt2.tmp_\\\\pystringtest%20(2).oxt\\\\pystringtest.py', > traceback follows > \X000a File \"C:\\Program Files\\LibreOffice\\program\\pythonloader.py\", line 146, in writeRegistryInfo > \X000a mod = self.getModuleFromUrl( locationUrl ) > \X000a File \"C:\\Program Files\\LibreOffice\\program\\pythonloader.py\", line 93, in getModuleFromUrl > \X000a with open( filename, encoding='utf_8' ) as fileHandle: > \X000a > \X000a", Context = (com.sun.star.uno.XInterface) @0 } } Indeed, there is no directory named 'pystringtest%20(2).oxt' under C:\Users\mikek\AppData\Roaming\LibreOffice\4\user\uno_packages\cache\uno_packages\lu233889xtt2.tmp_, the correct name is 'pystringtest (2).oxt', which is there. Tested with Version: 7.4.1.2 (x64) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
The problem is different encoding of the path sent from soffice.bin to uno.exe. The preparation of the path happens in PackageManagerImpl::addPackage, where title_enc (pystringtest%20(2).oxt) is an URL-encoded version of title (pystringtest (2).oxt), and destFolder is "vnd.sun.star.expand:$TMP_EXTENSIONS/extensions/lu233889xtt2.tmp_" created in insertToActivationLayer (using makeURL). Then these two are joined using another call to makeURL; the latter has a special processing of 'baseURL.match( "vnd.sun.star.expand:" )' case, which incidentally was also true for destFolder; and that processing uses encodeForRcFile and rtl::Uri::encode of the relative part; and the resulting URL is vnd.sun.star.expand:$TMP_EXTENSIONS/extensions/lu233889xtt2.tmp_/pystringtest%2520(2).oxt Now it's sent to uno.exe, which passes the URL to Loader.getModuleFromUrl (pyuno/source/loader/pythonloader.py). The latter processes '"vnd.sun.star.expand" == protocol' case, using expandMacros - but that's all. But how could the string after macro expansion be decoded reliably? There was at least two encoding passes *on unknown pieces* of the resulting thing, which currently looks like file://C:/Users/mikek/AppData/Roaming/LibreOffice/4/user/uno_packages/cache/uno_packages/lu233889xtt2.tmp_/pystringtest%20(2).oxt What if there were '$, {} \' in the expanded part that encodeForRcFile handles? What id that part contained %20 or the like? How many times should decode work on what pieces? I honestly don't know how to approach this.
(In reply to Mike Kaganski from comment #1) > which currently looks like > > file://C:/Users/mikek/AppData/Roaming/LibreOffice/4/user/uno_packages/cache/ > uno_packages/lu233889xtt2.tmp_/pystringtest%20(2).oxt Sorry, indeed it looks at that point like file://C:/Users/mikek/AppData/Roaming/LibreOffice/4/user/uno_packages/cache/uno_packages/lu233889xtt2.tmp_/pystringtest%2520(2).oxt
Repro with Version: 7.4.1.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.4.1~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded I got the same error as reported by the OP.
(In reply to Mike Kaganski from comment #1) > The problem is different encoding of the path sent from soffice.bin to > uno.exe. The preparation of the path happens in > PackageManagerImpl::addPackage, where title_enc (pystringtest%20(2).oxt) is > an URL-encoded version of title (pystringtest (2).oxt), and destFolder is > "vnd.sun.star.expand:$TMP_EXTENSIONS/extensions/lu233889xtt2.tmp_" created > in insertToActivationLayer (using makeURL). > > Then these two are joined using another call to makeURL; the latter has a > special processing of 'baseURL.match( "vnd.sun.star.expand:" )' case, which > incidentally was also true for destFolder; and that processing uses > encodeForRcFile and rtl::Uri::encode of the relative part; and the resulting > URL is > > vnd.sun.star.expand:$TMP_EXTENSIONS/extensions/lu233889xtt2.tmp_/ > pystringtest%2520(2).oxt > > Now it's sent to uno.exe, which passes the URL to Loader.getModuleFromUrl > (pyuno/source/loader/pythonloader.py). The latter processes > '"vnd.sun.star.expand" == protocol' case, using expandMacros - but that's > all. That Python code must URL-decode the vnd.sun.star.expand:... payload prior to passing it to expandMacros (cf. e.g. what bootstrap_expandUri in cppuhelper/source/bootstrap.cxx does).
(In reply to Stephan Bergmann from comment #4) > That Python code must URL-decode the vnd.sun.star.expand:... payload prior > to passing it to expandMacros (cf. e.g. what bootstrap_expandUri in > cppuhelper/source/bootstrap.cxx does). What is the proper way in Python: should urllib.parse.unquote be used, or is there something from URE available for Python?
(In reply to Mike Kaganski from comment #5) > What is the proper way in Python: should urllib.parse.unquote be used, or is > there something from URE available for Python? The css.uri UNO services don't provide such decoding directly, but they do provide css.uri.UriReferenceFactory's parse returning a css.uri.XVndSunStarExpandUrlReference instance with an expand method that does all of the decode-and-expand steps. So either use that directly or look around what other LO Python code uses for URL decoding.
https://gerrit.libreoffice.org/c/core/+/140042
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2875d11939679ec319e5b098a9b85da629781d5c tdf#150982: properly unquote (URL-decode) vnd.sun.star.expand payload It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/312704298ebff67db4a747014b8a0c5a306b665a tdf#150982: properly unquote (URL-decode) vnd.sun.star.expand payload It will be available in 7.4.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.