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.
