https://bugs.documentfoundation.org/show_bug.cgi?id=150982
--- Comment #1 from Mike Kaganski <mikekagan...@hotmail.com> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
