incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fan Zheng <zheng.easy...@gmail.com>
Subject Re: Propose for 3.4.1: Can't remove password from file (119366)
Date Thu, 28 Jun 2012 05:51:29 GMT
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 <polo8495@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: orwittmann@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message