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:57:14 GMT
And I my local, (WinXP env), seems such issues can not be reproduced.



2012/6/28 Fan Zheng <zheng.easyfan@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 <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