On pc Debian x86-64 with master source updated today.

Noel: one for you?

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!

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".

Ok, I had a bug in my macro with file name, the macro runned successfully completely.

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.

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

(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}}

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

It seems it's perhaps in fileaccess::TaskManager::endTask but I don't understand all this part.
I can't help here :-(

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}}

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. :)

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?).

(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.

(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.

(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.

(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.

It's now nearly a year since any comment was made on this subject. Is no-one looking at this?

Bug is still there in version 5.7.3 (latest stable).

(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.

(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.

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.

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.

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.

(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.

(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

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.

Unfortunately, we can hardly change the default flag for the overwrite option, so at least we throw an error when the file exists.

(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?

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.

(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.

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.

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

(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.

(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.)

(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.

(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.

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.