To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=98990
------- Additional comments from [email protected] Thu Feb 26 14:07:39 +0000 2009 ------- tags/OOO310_m3/scripting/source/pyprov/pyhtonscript.py has several severe flaws, it appears: 1 The PythonScriptProvider has a mapPackageName2Path populated in getPackageName2PathMap by iterating over the uno_packages/cache file system. In the case of the first add ScriptDispatch.oxt, the file system iteration is done at a time when the ScriptDispatch.oxt has already been unpacked in the uno_packages/cache, so the map has an (erroneous) entry (ScriptDispatch.oxt -> .../uno_packages/cache/uno_packages/TAG1/ScriptDispatch.oxt/ScriptDispatch/). A following hasByName(.../uno_packages/cache/uno_packages/TAG1/ScriptDispatch.oxt/ScriptDispatch/) thus erroneously returns true, and the extension is not properly installed (no basis layer share/Scripts/unopkg-desc.xml is written). In the case of a subsequent add -f ScriptDipatch.oxt (removing the already installed ScriptDispatch.oxt and installing it anew), the file system iteration is done at a time when both the old and new ScriptDispatch.oxt are unpacked in the uno_packages/cache. Depending on the file system traversal order, the resulting map either has a (correct) entry (ScriptDispatch.oxt -> .../uno_packages/cache/uno_packages/TAGold/ScriptDispatch.oxt/ScriptDispatch/) or an (erroneous) entry (ScriptDispatch.oxt -> .../uno_packages/cache/uno_packages/TAGnew/ScriptDispatch.oxt/ScriptDispatch/)---since both entries have the same key (ScriptDispatch.oxt), they overwrite one another. In the case where the file system traversal happens to finally record in the map the TAGold version, a following hasByName(.../uno_packages/cache/uno_packages/TAGold/ScriptDispatch.oxt/ScriptDispatch/) correctly returns true, a following removeByName(.../uno_packages/cache/uno_packages/TAGold/ScriptDispatch.oxt/ScriptDispatch/) removes the single entry from the map (which is then empty), so that a following hasByName(.../uno_packages/cache/uno_packages/TAGnew/ScriptDispatch.oxt/ScriptDispatch/) happens to correctly return false (and everything appears to work fine then). In the case where the file system traversal happens to finally record in the map the TAGnew version, a following hasByName(.../uno_packages/cache/uno_packages/TAGold/ScriptDispatch.oxt/ScriptDispatch/) erroneously returns false, and the extension re-installation does not work properly. It appears that on Windows the file system traversal always produces the second case (on Linux, if the following problem were fixed, the two cases would alternate). 2 Due to the 3-layer basis symlink on Unix, the file URLs produced by getPackageName2PathMap contain .. segments, while the URLs passed into hasByName are normalized (in expandUri) and thus no longer contain .. segments. This causes hasByName to always return false on Unix systems. (Each element of pathes at line 587 would have to be passed through uno.absolutize, as is done in expandUri.) 3 The code will always fail when there are different extensions that happen to have the same file name (but different extension identifiers)---see the discussion of mapPackageName2Path under (1). So, it seems a substantial redesign of pythonscript.py is necessary to fix this issue. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
