The error message "General Error: Generral input/output error" looks so farmilliar... I remember that in the build without moz package inside, such dialog will show up.
2012/6/28 YangTerry <polo8...@hotmail.com> > > Verify not fixed on trunk r1354384. > If we saved with our format(.ods) > Failed to saved with password, the failed message in dialog is "General > Error: Generral input/output error", also failed open the password protect > .ods file, it pop up password incorrect dialog but i input correct > password. Reopen this bug. > My Platform is Win 7 X64 EN.If we saved with MS format (.xls), > successfully saved it with password and also work fine to removed the > password. > Also work fine saved file(.ods) without password. > > Seems something wrong in our format save with password logic. > > > Date: Tue, 26 Jun 2012 16:27:56 +0200 > > From: orwittm...@googlemail.com > > To: ooo-dev@incubator.apache.org > > Subject: Re: Propose for 3.4.1: Can't remove password from file (119366) > > > > Hi, > > > > On 26.06.2012 14:05, Oliver-Rainer Wittmann wrote: > > > Hi, > > > > > > On 26.06.2012 09:53, Fan Zheng wrote: > > >> Root cause: > > >> > > >> Seems the logic of "Save As" and "Save" inside Apache OpenOffice is > pretty > > >> weird anyway. > > >> A, inside AOO, the method SfxBaseModel::StoreSelf is the entry for > storing > > >> file into the original URL path if it has one. Which means, such > method is > > >> responsible to: > > >> > > >> 1. Directly "Save" request, but exclude the very first time on "Save" > > >> without original URL path; > > >> > > >> 2. "SaveAs" request, with the same URL information as former; > > >> > > >> > > >> B, as such method is only focus on storing back into to original > file, it > > >> is designed as an incremental saving pattern for certain efficient > > >> consideration. Which means, > > >> such function do not allow external saving parameters except the ones > on > > >> changing "Version Comments", "Author", "Interaction Handler" and > "status > > >> Indicator". > > >> > > >> C, "Saving with password" is a kind of external saving parameter. The > > >> saving parameters set will contain a password item inside, if users > have > > >> enable the check box > > >> "Save with password" in "File Save As" dialog. Otherwise, saving > parameters > > >> set wont contain password corresponding items. > > >> > > >> Combine the above 3 conditions, we can take a deeper inside look of > > >> following scenarios: > > >> > > >> 1. In the "Save" request, whatever the password originally enabled or > not, > > >> as no further different setting applied, the storing process will > directly > > >> apply the former saving parameters set, including the URL path and > password > > >> setting stuff. Everything is OK. > > >> > > >> 2. And in the "SaveAs" request with password originally disabled: > > >> 2.1 If the user keep the "Save with password" disabled in "File Save > As" > > >> dialog, as no further setting applied, the storing process will > directly > > >> apply the former saving parameters set, still with password disabled. > Keep > > >> the consistence between UI setting and exact result and high > efficiency; > > >> 2.2 If the user change the "Save with password" from disable to > enable in > > >> "File Save As" dialog, as external saving parameter was added into > saving > > >> parameters set, which do not satisfy the verification of parameters, > such > > >> "SaveAs" request will be returned from SfxBaseModel::StoreSelf, and > > >> actually finished inside the common "SaveAs" method with password > enabled. > > >> Also keep the consistence between UI setting and exact result; > > >> 3. In the "SaveAs" request with password originally enabled: > > >> 3.1 If the user keep the "Save with password" enabled in "File Save > As" > > >> dialog, as external saving parameter was added into saving parameters > set, > > >> which do not satisfy the verification of parameters, such "SaveAs" > request > > >> will be returned from SfxBaseModel::StoreSelf, and actually finished > inside > > >> the common "SaveAs" method with password enabled. Keep the consistence > > >> between UI setting and exact result, but with lower efficiency; > > >> 3.2 If the user change the "Save with password" from enabled to > disabled in > > >> "File Save As" dialog, as no further setting applied, the storing > process > > >> will directly apply the former saving parameters set, still with > password > > >> enabled, as oppose to the UI setting. The issue happens. > > >> > > >> So, a reasonable solution of this issue should be: > > >> > > >> 1. No process and saving parameter change on scenario 1 and 2; > > >> 2. In scenario 3.1, remove the external password parameter as the > > >> originally enabled, and makes it finished in StoreSelf for higher > > >> efficiency; > > >> 3. In scenario 3.2, do not trying to use StoreSelf anyway; > > >> > > >> > > >> For you reference. > > >> > > >> The code patch will be submitted for reviewing later. > > >> > > > > > > Thanks for this really deep and well founded analysis. > > > > > > I am currently reviewing the new patch. > > > > > > > > > > patch looks good - I will commit it to trunk and branch AOO34 soon. > > Thx ZhengFan. > > > > Best regards, Oliver. > >
