Bug 60237 - : Bug in API call StoreAsURL (or in the OO Basic API description)
Summary: : Bug in API call StoreAsURL (or in the OO Basic API description)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: Other All
: medium normal
Assignee: Andreas Heinisch
URL:
Whiteboard: BSA target:7.2.0
Keywords: haveBacktrace
Depends on:
Blocks: Macro-VBA
  Show dependency treegraph
 
Reported: 2013-02-03 14:39 UTC by Peter Toye
Modified: 2022-05-05 11:29 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Toye 2013-02-03 14:39:52 UTC
Problem description: When saving a file using StoreAsURL with the MediaDescriptor property "Overwrite" not set (i.e. using the default, which the documentation describes as having the value FALSE), existing files are overwritten.

Steps to reproduce:

Edit the following macro to conform to your local directory structure and OS, put a Writer file called "Test1.odt" in the directory and run the macro.

Sub Main

dim FileString as String
dim TrueProp as  Object
TrueProp = New com.sun.star.beans.PropertyValue
dim FalseProp as Object
FalseProp = New com.sun.star.beans.PropertyValue

TrueProp.Name="Overwrite"
TrueProp.Value=TRUE
FalseProp.Name="Overwrite"
FalseProp.Value=FALSE

dim EmptyArray() as Object
dim TrueArray(0) as Object
dim FalseArray(0) as Object

TrueArray(0)=TrueProp
FalseArray(0)=FalseProp

InFileString=  "D:\Peter\PC\Open Office\Bughunt\Test1.odt"  ' This file already exists
OutFile2String="D:\Peter\PC\Open Office\Bughunt\Test2.odt" 
OutFile3String="D:\Peter\PC\Open Office\Bughunt\Test3.odt" 
OutFile4String="D:\Peter\PC\Open Office\Bughunt\Test4.odt" 

dim FileURL as String

InFileURL=ConverttoURL(InFileString)
OutFile2URL=ConverttoURL(OutFile2String)
OutFile3URL=ConverttoURL(OutFile3String)
OutFile4URL=ConverttoURL(OutFile4String)

Dim doc as Object

Doc=StarDesktop.LoadComponentfromURL(InFileURL, "_blank", 0, Array())
msgbox "Document loaded"
'xray doc

Doc.StoreToURL(OutFile2URL,TrueArray)
Doc.StoreToURL(OutFile3URL,TrueArray)
Doc.StoreToURL(OutFile4URL,TrueArray)
msgbox "Documents 2,3,4 stored OK"

Doc.StoreAsURL(OutFile2URL,TrueArray)
msgbox "Document 2 stored with Overwrite set to TRUE"

Doc.StoreAsURL(OutFile3URL,EmptyArray)
msgbox "Document 3 stored with default Overwrite"

Doc.StoreAsURL(OutFile4URL,FalseArray)
msgbox "Document 4 stored with Overwrite set to FALSE"

End sub

Current behavior:

Gives an error when storing Document Test4.

Expected behavior:

Should have given an error when storing document Test3.

This also occurs in OpenOffice and has been reported as bug no 121665 there.

              
Operating System: Windows 7
Version: 3.5.7.2 release
Comment 1 Julien Nabet 2013-02-17 00:23:47 UTC
On pc Debian x86-64 with master source updated today.

Noel: one for you?
Comment 2 QA Administrators 2015-02-19 15:45:55 UTC Comment hidden (obsolete)
Comment 3 Peter Toye 2015-02-19 18:38:01 UTC
I tried it with LO 4.3.5.2 under Windows 7 64-bit home premium. No change in behaviour.

I think that this is an extremely annoying bug, even though the workaround is to ALWAYS use a property list when calling StoreToURL. The default behaviour overwrites a file without warning - never good behaviour for a default! At the very least the documentation should be changed to reflect the current behaviour of StoreToURL with a great big warning message.

Apache don't seem to agree with me and think it's trivial. Having overwritten a file (fortunately backed up) by assuming that the documentation is correct I can't agree!
Comment 4 Julien Nabet 2015-02-19 19:28:28 UTC
On pc Debian x86-64 with master sources updated today, I got this error when launching macro:
BASIC runtime error.
An exception occurred 
Type: com.sun.star.lang.IllegalArgumentException
Message: Unsupported URL <file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test1.odt>: "type detection failed".
Comment 5 Julien Nabet 2015-02-19 19:29:52 UTC
Ok, I had a bug in my macro with file name, the macro runned successfully completely.
Comment 6 Julien Nabet 2015-02-19 19:57:01 UTC
Oups, forget what I indicated, I indeed reproduced the pb, here's the error message for the fourth file:
BASIC runtime error.
An exception occurred 
Type: com.sun.star.task.ErrorCodeIOException
Message: SfxBaseModel::impl_store <file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test4.odt> failed: 0x20d.
Comment 7 Julien Nabet 2015-02-19 20:12:58 UTC
In gdb session with "catch throw ErrorCodeIOException", I could retrieved a bt, here's main part:
 #0  0x00002aaaabcb6dbd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00002aaaaed7c994 in SfxBaseModel::impl_store (this=0x7306430, sURL="file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test4.odt", 
    seqArguments=uno::Sequence of length 1 = {...}, bSaveTo=false) at /home/julien/compile-libreoffice/libreoffice/sfx2/source/doc/sfxbasemodel.cxx:3137
#2  0x00002aaaaed7457e in SfxBaseModel::storeAsURL (this=0x7306430, rURL="file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test4.odt", 
    rArgs=uno::Sequence of length 1 = {...}) at /home/julien/compile-libreoffice/libreoffice/sfx2/source/doc/sfxbasemodel.cxx:1662
#3  0x00002aaac3d59fef in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*)
    () from /home/julien/compile-libreoffice/libreoffice/instdir/program/libgcc3_uno.so
#4  0x00002aaac3d58fc5 in cpp_call (pThis=0x692d600, aVtableSlot=..., pReturnTypeRef=0x648060, nParams=2, pParams=0x684ba80, pUnoReturn=0x7fffffff3c10, 
    pUnoArgs=0x7fffffff3be0, ppUnoExc=0x7fffffff3c58) at /home/julien/compile-libreoffice/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:231
#5  0x00002aaac3d599df in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0x692d600, pMemberDescr=0x684c9e0, pReturn=0x7fffffff3c10, pArgs=0x7fffffff3be0, 
    ppException=0x7fffffff3c58) at /home/julien/compile-libreoffice/libreoffice/bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:429
#6  0x00002aaad097bd43 in stoc_corefl::IdlInterfaceMethodImpl::invoke (this=0x684cce0, rObj=
    uno::Any {<com::sun::star::uno::XInterface> = {_vptr.XInterface = 0x7306328}, <No data fields>}, rArgs=uno::Sequence of length 2 = {...})
    at /home/julien/compile-libreoffice/libreoffice/stoc/source/corereflection/criface.cxx:706
#7  0x00002aaaae4030e3 in SbUnoObject::Notify (this=0x755bbe0, rBC=..., rHint=...) at /home/julien/compile-libreoffice/libreoffice/basic/source/classes/sbunoobj.cxx:2286
#8  0x00002aaaaf685418 in SfxBroadcaster::Broadcast (this=0x6a23930, rHint=...) at /home/julien/compile-libreoffice/libreoffice/svl/source/notify/SfxBroadcaster.cxx:51
#9  0x00002aaaae50ea0e in SbxVariable::Broadcast (this=0x747d8f0, nHintId=65536) at /home/julien/compile-libreoffice/libreoffice/basic/source/sbx/sbxvar.cxx:182
#10 0x00002aaaae508773 in SbxValue::SbxValue (this=0x76ce3e0, __vtt_parm=0x2aaaae81a210 <VTT for SbxMethod+16>, r=..., __in_chrg=<optimized out>)
    at /home/julien/compile-libreoffice/libreoffice/basic/source/sbx/sbxvalue.cxx:100
#11 0x00002aaaae50df92 in SbxVariable::SbxVariable (this=0x76ce3e0, __vtt_parm=0x2aaaae81a208 <VTT for SbxMethod+8>, r=..., __in_chrg=<optimized out>)
    at /home/julien/compile-libreoffice/libreoffice/basic/source/sbx/sbxvar.cxx:77
#12 0x00002aaaae500f12 in SbxMethod::SbxMethod (this=0x76ce3e0, r=..., __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /home/julien/compile-libreoffice/libreoffice/basic/source/sbx/sbxobj.cxx:900
Comment 8 Julien Nabet 2015-02-19 20:14:26 UTC
(gdb) p seqArguments
$1 = uno::Sequence of length 1 = {{Name = "Overwrite", Handle = 0, Value = uno::Any 0 '\000', State = com::sun::star::beans::PropertyState_DIRECT_VALUE}}
Comment 9 Julien Nabet 2015-02-19 21:27:33 UTC
Trying to unwind with gdb, it seems to come from SfxMedium::Transfer_Impl(), see
http://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx#1732

I'll try to find some time to keep on
Comment 10 Julien Nabet 2015-02-20 22:26:19 UTC
It seems it's perhaps in fileaccess::TaskManager::endTask but I don't understand all this part.
I can't help here :-(
Comment 11 Julien Nabet 2015-02-21 00:53:00 UTC
code pointers
When it's ok:
Breakpoint 5, SfxBaseModel::storeAsURL (this=0x76e8c50, rURL="file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test2.odt", 
    rArgs=uno::Sequence of length 1 = {...}) at /home/julien/compile-libreoffice/libreoffice/sfx2/source/doc/sfxbasemodel.cxx:1662
1662	        impl_store( rURL, rArgs, false );
(gdb) p rArgs
$11 = uno::Sequence of length 1 = {{Name = "Overwrite", Handle = 0, Value = uno::Any 1 '\001', State = com::sun::star::beans::PropertyState_DIRECT_VALUE}}

or even:
Breakpoint 5, SfxBaseModel::storeAsURL (this=0x76e8c50, rURL="file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test3.odt", rArgs=empty uno::Sequence)
    at /home/julien/compile-libreoffice/libreoffice/sfx2/source/doc/sfxbasemodel.cxx:1662
1662	        impl_store( rURL, rArgs, false );


When it's ko:
Breakpoint 5, SfxBaseModel::storeAsURL (this=0x76e8c50, rURL="file:///home/julien/compile-libreoffice/bugs/60237_macrostore/Test4.odt", 
    rArgs=uno::Sequence of length 1 = {...}) at /home/julien/compile-libreoffice/libreoffice/sfx2/source/doc/sfxbasemodel.cxx:1662
1662	        impl_store( rURL, rArgs, false );
(gdb) p rArgs
$13 = uno::Sequence of length 1 = {{Name = "Overwrite", Handle = 0, Value = uno::Any 0 '\000', State = com::sun::star::beans::PropertyState_DIRECT_VALUE}}
Comment 12 Aron Budea 2015-02-23 16:29:42 UTC
I'm by no means an expert, but after debugging this issue, the following piece of code looks really suspicious:

In method SfxMedium::TransactedTransferForFS_Impl, here
http://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx#1586 :

SFX_ITEMSET_ARG( GetItemSet(), pOverWrite, SfxBoolItem, SID_OVERWRITE, false );
SFX_ITEMSET_ARG( GetItemSet(), pRename, SfxBoolItem, SID_RENAME, false );
bool bRename = pRename && pRename->GetValue();
bool bOverWrite = pOverWrite ? pOverWrite->GetValue() : !bRename;

The possibilities:
-SID_OVERWRITE is set: that value is used
-SID_OVERWRITE is not set:
        -SID_RENAME is set: the opposite of SID_RENAME is used
        -SID_RENAME is not set (bRename is false): bOverWrite becomes true <= this is what happens in example 3

I hope that helps. :)
Comment 13 Peter Toye 2015-02-23 19:05:16 UTC
I am in no way competent to suggest a programming cure for this, but I think we have to be vary careful in doing so. There may be users who have written macros which make use of the current default behaviour, and which will stop working as designed if the LO code is changed. 

As I have written elsewhere, default behaviour which is destructive should be deprecated, but I have a nasty feeling that we are rather stuck with it. Apart from modifying the documentation to highlight this behaviour, is there anything else we can do? I have done this in the tutorial https://wiki.openoffice.org/wiki/Saving_a_document but as I am not an AOO or LO developer I don't think I can (or should) modify the basic API documentation without the agreement of the devlopment teams. 

There is also the issue of a split in functionality between LO and AOO (or do the dev teams talk to each other?).
Comment 14 LeMoyne Castle 2015-02-26 04:58:56 UTC
(In reply to Aron Budea from comment #12)
> I'm by no means an expert, but after debugging this issue, the following
> piece of code looks really suspicious:
> 
...
> bool bRename = pRename && pRename->GetValue();
> bool bOverWrite = pOverWrite ? pOverWrite->GetValue() : !bRename;

Aron, the SID_xxx values are compile time constants that are available.  If the SID_xxx, RID_xxx tables get messed up LibreOffice will almost certainly crash at start. 

I think this is working as desired: the Overwrite value will be used if given, but if it's not LibO will only overwrite a file of the same name.  

I can see how overwriting a file of the same name can cause data loss and if one is in that situation then adding a time stamp to the file name will avoid the loss.  

The default is not exactly false, it is false (=no overwrite) except when the save would overwrite a file of the same name.  This is a core save routine in Writer and no one would be happy with a word processor that insisted on asking about overwrites everytime a file was saved again.  So, in my opinion, the issue is with the documentation.
Comment 15 Aron Budea 2015-03-01 18:33:04 UTC
(In reply to lo from comment #13)
> As I have written elsewhere, default behaviour which is destructive should
> be deprecated, but I have a nasty feeling that we are rather stuck with it.
> Apart from modifying the documentation to highlight this behaviour, is there
> anything else we can do? I have done this in the tutorial
> https://wiki.openoffice.org/wiki/Saving_a_document but as I am not an AOO or
> LO developer I don't think I can (or should) modify the basic API
> documentation without the agreement of the devlopment teams. 

I don't agree that it should ultimately be considered as an issue in the API documentation, because the API usage is based on that documentation, and users expect the functions to work as described there. If someone wanted to use this function, they must've expected that Overwrite would be false by default, based on the documentation.
If they noticed the contradiction between the documentation and actual behavior, and relied on the way it worked, that's a deliberate action (and a serious mistake).
On the other hand there might also be code out there that relies on the documented default value of the Overwrite flag, and the bug simply went unnoticed.
Comment 16 Aron Budea 2015-03-01 18:42:17 UTC
(In reply to LeMoyne Castle from comment #14)
> Aron, the SID_xxx values are compile time constants that are available.  If
> the SID_xxx, RID_xxx tables get messed up LibreOffice will almost certainly
> crash at start. 

My bad if I wasn't clear, I was not implying to meddle with the SID_xxx constants, I was only referring to the property values stored with those IDs.

> I think this is working as desired: the Overwrite value will be used if
> given, but if it's not LibO will only overwrite a file of the same name.  

No it isn't, it overwrites any file, not only if it has the same URL.
Plus if the desired behavior is to save over the same file, the store() function is designed for that purpose.

I'm not sure which core save routine in Writer you're reffering to, but if you try to overwrite the same file with Save As... (which storeAsURL() resembles the closest), it's not going to without asking first.
Comment 17 Peter Toye 2015-11-26 12:02:28 UTC
(In reply to Aron Budea from comment #15)

So where does this leave us? At the moment the code and documentation differ - at least one should change.

> I don't agree that it should ultimately be considered as an issue in the API
> documentation, because the API usage is based on that documentation, and
> users expect the functions to work as described there. If someone wanted to
> use this function, they must've expected that Overwrite would be false by
> default, based on the documentation.
I agree with this, provided that changing the code to reflect the documentation isn't going to stop existing programs from working.

> If they noticed the contradiction between the documentation and actual
> behavior, and relied on the way it worked, that's a deliberate action (and a
> serious mistake).
One has to rely on the way it works, so it's not a mistake! I could have simply decided to remember each time I saved that it should be to a different file (unless I really wanted to overwrite). Of course I didn't and set the Overwrite flag to prevent overwriting.

> On the other hand there might also be code out there that relies on the
> documented default value of the Overwrite flag, and the bug simply went
> unnoticed.
...and overwrote a file (as happened to me)! 

My personal view is that the code should be changed to reflect the documentation, which in my opinion is the desired behaviour. But I have no idea if the LO development team feel that current behaviour should take priority over documentation. Maybe someone from that team could comment. I'm only a user so I don't know the correct form to get action, but it's been 8 months since any comments on this issue.
Comment 18 Peter Toye 2016-11-18 14:36:57 UTC
It's now nearly a year since any comment was made on this subject. Is no-one looking at this?
Comment 19 QA Administrators 2017-11-19 19:15:16 UTC Comment hidden (obsolete)
Comment 20 Peter Toye 2017-11-20 18:40:39 UTC
Bug is still there in version 5.7.3 (latest stable).
Comment 21 Peter Toye 2017-11-20 19:12:29 UTC
(In reply to Peter Toye from comment #20)
> Bug is still there in version 5.7.3 (latest stable).

Version: 5.3.7.2 (x64)
Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: en-GB (en_GB); Calc: group


Sorry forgot to add this.
Comment 22 Peter Toye 2019-05-30 11:03:13 UTC
(In reply to Aron Budea from comment #16)
> (In reply to LeMoyne Castle from comment #14)
> > Aron, the SID_xxx values are compile time constants that are available.  If
> > the SID_xxx, RID_xxx tables get messed up LibreOffice will almost certainly
> > crash at start. 
> 
> My bad if I wasn't clear, I was not implying to meddle with the SID_xxx
> constants, I was only referring to the property values stored with those IDs.
> 
> > I think this is working as desired: the Overwrite value will be used if
> > given, but if it's not LibO will only overwrite a file of the same name.  
> 
> No it isn't, it overwrites any file, not only if it has the same URL.
> Plus if the desired behavior is to save over the same file, the store()
> function is designed for that purpose.
> 
> I'm not sure which core save routine in Writer you're reffering to, but if
> you try to overwrite the same file with Save As... (which storeAsURL()
> resembles the closest), it's not going to without asking first.

Is anything happening on this? I reported it 6 years ago and the last comment was from Aron in 2015! There's not much point in a bug reporting system if the dev team dno't look at it.
Comment 23 Andreas Heinisch 2021-01-26 18:11:57 UTC
Tested again with:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 85940a9a96ecd3adbd0af7aed78220b0cb82daf0
CPU threads: 6; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL

and

Version: 6.3.3.2 (x64)
Build-ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU-Threads: 6; BS: Windows 10.0; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: CL

Gives no error at all.
Comment 24 Andreas Heinisch 2021-01-26 18:13:04 UTC
However, in 

Version: 4.4.0.1
Build-ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f

gives no error when storing document Test3 and throws an error when storing document Test4.
Comment 25 Andreas Heinisch 2021-01-26 18:36:24 UTC
Imho, the expected and documented behaviour should be the following for the MediaDescriptor property "Overwrite":

- set to true: any existing file should be overwritten
- set to false: file should never be overwritten and we should produce an error, if the file already exists
- set to none: using the default case (false) as stated in the documentation

It could possibly affect users, but I will include explanations in the release notes after I come up with a patch.
Comment 26 Peter Toye 2021-01-27 11:18:59 UTC
(In reply to Andreas Heinisch from comment #25)
> Imho, the expected and documented behaviour should be the following for the
> MediaDescriptor property "Overwrite":
> 
> - set to true: any existing file should be overwritten
> - set to false: file should never be overwritten and we should produce an
> error, if the file already exists
> - set to none: using the default case (false) as stated in the documentation
> 
> It could possibly affect users, but I will include explanations in the
> release notes after I come up with a patch.

As the originator of this thread I agree, as I said in comment #13 (how do you put links to comments into a reply?). Default behaviour should _never_ be destructive.
Comment 27 Peter Toye 2021-01-27 11:20:40 UTC
(In reply to Andreas Heinisch from comment #24)
> However, in 
> 
> Version: 4.4.0.1
> Build-ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f
> 
> gives no error when storing document Test3 and throws an error when storing
> document Test4.

I get no error on storing Document 4 in LO 7.0

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded
Comment 28 Commit Notification 2021-02-01 08:38:17 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a62878ff86ecb38f9ea9fbe99f06518ed6016566

tdf#60237 - correct the behaviour of the Overwrite property

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 29 Andreas Heinisch 2021-02-01 10:31:44 UTC
Unfortunately, we can hardly change the default flag for the overwrite option, so at least we throw an error when the file exists.
Comment 30 Peter Toye 2021-02-01 15:56:56 UTC
(In reply to Andreas Heinisch from comment #29)
> Unfortunately, we can hardly change the default flag for the overwrite
> option, so at least we throw an error when the file exists.

I don't quite understand this. There are two differing meanings for the default flag: the documented one and the behaviour of the code. Which do you mean?
Comment 31 Andreas Heinisch 2021-02-01 16:57:13 UTC
We changed the documented one, so the default is now true in the documentation and in the code. However, if you explicitly set the flag to OverWrite to false, you get an exception, if the file already exists.
Comment 32 Mike Kaganski 2022-05-03 08:16:47 UTC
(In reply to Andreas Heinisch from comment #25)
> Imho, the expected and documented behaviour should be the following for the
> MediaDescriptor property "Overwrite":
> 
> - set to true: any existing file should be overwritten
> - set to false: file should never be overwritten and we should produce an
> error, if the file already exists
> - set to none: using the default case (false) as stated in the documentation

I am unsure that the description here is correct.

(In reply to Aron Budea from comment #12)
> In method SfxMedium::TransactedTransferForFS_Impl, here
> http://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx#1586 :
> 
> SFX_ITEMSET_ARG( GetItemSet(), pOverWrite, SfxBoolItem, SID_OVERWRITE, false
> );
> SFX_ITEMSET_ARG( GetItemSet(), pRename, SfxBoolItem, SID_RENAME, false );
> bool bRename = pRename && pRename->GetValue();
> bool bOverWrite = pOverWrite ? pOverWrite->GetValue() : !bRename;
> 
> The possibilities:
> -SID_OVERWRITE is set: that value is used
> -SID_OVERWRITE is not set:
>         -SID_RENAME is set: the opposite of SID_RENAME is used
>         -SID_RENAME is not set (bRename is false): bOverWrite becomes true
> <= this is what happens in example 3

This is very useful, but the description is not completely correct.
The idea is this.

When the *current* file name of the document is the same as the new name, it is considered that we are just saving edits to the same file; in this case, we should not error out when the file exists - ever.

When the file name is different, we must honor the overwrite flag.

And the rename flag is expected to reflect the "new name is same as old name".

So the bug here is that when user didn't provide the rename flag manually, it defaults to false, when it should be calculated according the two names.
Comment 33 Mike Kaganski 2022-05-03 09:20:06 UTC
FTR:

This commit has removed the unused SID_RENAME:

commit fa135fd0e05fc4ba784b4349d65f2e5ed26c0f55	[log]
  author Noel Grandin <noel@peralex.com>
  date   Tue May 31 10:30:35 2016 +0200
    remove unused SID constants and associated code

the SID was indeed unused, but that has made the underlying idea unclear (see comment 32). IMO, the current state is still inconsistent.
Comment 34 Mike Kaganski 2022-05-03 10:01:58 UTC
FTR: the relevant commits touching SID_RENAME

commit fd069bee7e57ad529c3c0974559fd2d84ec3151a
  author Jens-Heiner Rechtien <hr@openoffice.org>
  date   Mon Sep 18 16:07:07 2000 +0000
    initial import

   >>> set SID_RENAME in SfxObjectShell::ExecFile_Impl

commit f560dd6d4d54c2684273c2437ff4ff92635450cc
  author Mathias Bauer <mba@openoffice.org>
  date   Mon Sep 02 10:41:09 2002 +0000
    #102830#: check Overwrite flag

commit 2f68da4cfd0a107f1eec2fec10e31193539032e5
  author Kurt Zenker <kz@openoffice.org>
  date   Wed Jan 28 18:14:07 2004 +0000
    INTEGRATION: CWS filtercfg (1.58.6); FILE MERGED

   >>> dropped the code setting it from fd069bee7e57ad529c3c0974559fd2d84ec3151a

commit 762dd2b15bfd201b2271b460efa72a5b68d6fb2a
  author Kurt Zenker <kz@openoffice.org>
  date   Mon Oct 04 19:53:11 2004 +0000
    INTEGRATION: CWS mav09 (1.137.42); FILE MERGED

commit 2f9a82267a5bacd13248da083ae082c16096601f
  author Oliver Bolte <obo@openoffice.org>
  date   Mon Mar 27 08:35:31 2006 +0000
    INTEGRATION: CWS fwk36 (1.176.48); FILE MERGED

commit ef3e6790015f17c5301a910ea75718b43930b039
  author Rüdiger Timm <rt@openoffice.org>
  date   Tue Dec 16 09:00:18 2008 +0000
    CWS-TOOLING: integrate CWS mav45_DEV300
Comment 35 Peter Toye 2022-05-03 15:27:36 UTC
(In reply to Mike Kaganski from comment #33)
> FTR:
> 
> This commit has removed the unused SID_RENAME:
> 
> commit fa135fd0e05fc4ba784b4349d65f2e5ed26c0f55	[log]
>   author Noel Grandin <noel@peralex.com>
>   date   Tue May 31 10:30:35 2016 +0200
>     remove unused SID constants and associated code
> 
> the SID was indeed unused, but that has made the underlying idea unclear
> (see comment 32). IMO, the current state is still inconsistent.

I'm getting a bit lost here, as the discussion seems to have moved from my original point (that the documentation and implementation are inconsistent, and that the documented behaviour should be the implemented one) to details about coding (with which I am unfamiliar). Can someone (Mike?) please make it clear what the proposed code change will actually implement?

Comment 32 rather implies that if the file names are the same and no overwrite property is given, the file should be overwritten. This is exactly what should not happen, and does not happen in many other applications (including Libre Office!) which have a 'Save As...' button - a window comes up saying that the user is trying to save a file onto itself.
Comment 36 Mike Kaganski 2022-05-03 15:43:01 UTC
(In reply to Peter Toye from comment #35)
> Comment 32 rather implies that if the file names are the same and no
> overwrite property is given, the file should be overwritten. This is exactly
> what should not happen

I seem to be unclear here.

Say, you have a document represented by your `doc` variable. You have loaded it from "D:\Peter\PC\Open Office\Bughunt\Test1.odt". Now what should happen when you call `Doc.storeAsURL("D:\Peter\PC\Open Office\Bughunt\Test1.odt",EmptyArray)`? (forget about URL-vs-localpath in my code, just think about the idea.)

The describes scenario is identical to just using File->Save, and re-writes *already existing* "D:\Peter\PC\Open Office\Bughunt\Test1.odt" with the content of the `doc` that represented *the same* file. It's the same as calling `doc.store()`.

Or do you think that *in this case* we should block the write? (In the ideal case I mean, if this could be fixed as it was intended from the start.)
(By the way, I do not propose any patches now - it is just a bug that makes me sad because it can't be resolved properly for compatibility reasons.)
Comment 37 Peter Toye 2022-05-03 16:40:56 UTC
(In reply to Mike Kaganski from comment #36)
> (In reply to Peter Toye from comment #35)
> > Comment 32 rather implies that if the file names are the same and no
> > overwrite property is given, the file should be overwritten. This is exactly
> > what should not happen
> 
> I seem to be unclear here.
> 
> Say, you have a document represented by your `doc` variable. You have loaded
> it from "D:\Peter\PC\Open Office\Bughunt\Test1.odt". Now what should happen
> when you call `Doc.storeAsURL("D:\Peter\PC\Open
> Office\Bughunt\Test1.odt",EmptyArray)`? (forget about URL-vs-localpath in my
> code, just think about the idea.)
> 
> The describes scenario is identical to just using File->Save, and re-writes
> *already existing* "D:\Peter\PC\Open Office\Bughunt\Test1.odt" with the
> content of the `doc` that represented *the same* file. It's the same as
> calling `doc.store()`.
> 
> Or do you think that *in this case* we should block the write? (In the ideal
> case I mean, if this could be fixed as it was intended from the start.)
> (By the way, I do not propose any patches now - it is just a bug that makes
> me sad because it can't be resolved properly for compatibility reasons.)

The issue seems to be as to whether storeAsURL without an Overwrite parameter corresponds to a 'Save' or a 'Save as' action. The documentation implies the latter. You think the former. IMHO whenever there is doubt, one should choose the path which does the least damage. In this case, it would be the 'Save As' interpretation which avoids an overwrite.

You say (correctly) that compatibility reasons prevent this, I am sad too - see my comment 13. The documentation I've seen for MediaDescriptor defines the behaviour if Overwrite is set to TRUE or FALSE, but not if it is omitted. This needs to be fixed. So I'm reopening this bug.
Comment 38 Mike Kaganski 2022-05-05 11:13:57 UTC
(In reply to Peter Toye from comment #37)

I fail to see what is missing at https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1document_1_1MediaDescriptor.html#a12eb260687f0a1877ef020d242a1c4c6.
Comment 39 Peter Toye 2022-05-05 11:29:37 UTC
Sorry Mike - you're 100% right. I must have been asleep. I still don't like it, but we seem to be stuck with it. I'll close it off.