Apache OpenOffice (AOO) Bugzilla – Issue 100040
macro migration fails for forms with non-ascii names
Last modified: 2009-05-18 04:16:43 UTC
- open the attached database document - confirm the macro migration info dialog - Tools / Migrate Macros ... - repeatedly click "Next" in the macro migration dialog, using default settings - when the migration is finished, close the dialog - close the document - re-open the document - double-click the contained form => you get a warning about the form containing macros This is already weird, this warning already came when you opened the DBDoc => when the form is opened, you get an error message saying that a macro could not be found. This actually indicates that the macros were not properly migrated
Created attachment 60821 [details] document to reproduce the bug case
This issue was already fixed, though I don't have the issue number at hand. Seems it re-appeared. Nominating as 3.1 blocker.
issue 95865 is the previous incarnation of this problem ...
fs->mav: Most probably a regression of CWS mav44. There, you fixed the problem that ZIp packages can contain ascii characters only (or at least a very limited superset thereof, do not remember completely), namely issue 95409. In this course, you also adjusted the IsValidZipEntryFileName. Our macro migration wizard uses this function to determine which storage names need to be translated. Since mav44, umlauts (and probably other non-ASCII characters as well) which previously were not accepted by the function now *are* accepted, which means we create storages containing those characters. However, the safe process then throws a lot of assertions (in a non-product version) from module package and embeddedobj, and finally leaves a corrupted document. I am not yet sure who's responsible for the corruption: Some instance obviously ignores the thrown exceptions. I will continue to investigate, but I think you should fix the probem with IsValidZipEntryFileName not doing what it promises to do.
cc me
The error in writing the storage is properly propagated (i.e. raised as exception in the XTransactedObject::commit implementation), but unfortunately the database document silenced this exception in this particular case. I committed code to dba31j which changed this, so now the macro migration properly reports an error. Which doesn't fix the root cause, of course, but at least the data loss.
There is a problem in package implementation that has affected the scenario, the transportation of streams with non-ascii names from old package version to the new one was done errorneously. The fix is ready and easy. Unfortunately the API tests, that are intended to test the Unicode support did not cover the scenario. I will extend the tests-set in close future. Anyway, the fix in database document from fs is necessary. It is always possible that the commit process is interrupted ( for example in case there is not enough place or in case of network outage ). mav->fs: I assume, that it makes sense to integrate my fix to cws dba31j as well if it is intended to be used for OOo3.1 showstoppers.
fs->mav: Sure, feel free to commit your fix to dba31j
The fix for the package problem is now commited in dba31j.
fs->msc: please verify in CWS dba31j
verified in cws dba31j
Checked w/ OO.o 3.1 Ubuntu 9.04 (x86_64) using bug document. Closing