And I my local, (WinXP env), seems such issues can not be reproduced.
2012/6/28 Fan Zheng <zheng.easy...@gmail.com> > 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. >> >> > >
