Here is some code which shows the problem

REM  *****  BASIC  *****

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

FileString=    "some suitable file string"

dim FileURL as String

FileURL=ConverttoURL(FileString)

Dim doc as Object

Doc=StarDesktop.LoadComponentfromURL(FileURL, "_blank", 0, Array())
msgbox "Document loaded"

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

Doc.StoreAsURL(FileURL,EmptyArray)
msgbox "Document stored with default Overwrite" ' shouldn't be displayed but is

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


End sub

Created attachment 80170 [details]
Text document with AOO Basic macro

The macro:

1. creates a new empty text document
2. stores the document to a URL, with empty media descriptor, making sure that the URL does not point to nay existent document
3. stores the document to the same URL, with an empty media descriptor. The macro should fail, because the URL point to an existent file, stored in step 2

(In reply to comment #0)
> When storing a document with a null parameter list for the IArguments
> parameter it overwrites an existing document. The definition in
> http://www.openoffice.org/api/docs/common/ref/com/sun/star/document/
> MediaDescriptor.html says that the default value is FALSE, implying that
> this should give an error.
> 
> If the property is explicitly set to FALSE the program behaves as expected.
> 
> I don't know if this is a code or documentation error.

I can't reproduce it with the macro on attachment 80170 [details]

Can you upload a sample document? Please don't hard-code URLs in the sample.

Did you look at my program, or did I post it too late for you?

I might be misunderstanding the documentation here: does the OVERWRITE parameter live with the document and mark it as not overwriteable? Isn't this the same as read-only? It's certainly not how I read the documentation of MediaDescriptor, which says "overwrite any existing file".

(In reply to comment #4)
> Did you look at my program, or did I post it too late for you?

I don't understand your example, and what it is trying to proof. In which line is supposed to be the error while performing what action?

> I might be misunderstanding the documentation here: does the OVERWRITE
> parameter live with the document and mark it as not overwriteable? Isn't
> this the same as read-only? It's certainly not how I read the documentation
> of MediaDescriptor, which says "overwrite any existing file".

The following statement is not true:

> When storing a document with a null parameter list for the IArguments
> parameter it overwrites an existing document.

If you store a document to an URL where *another* document exists, and "Overwrite" is not set in the MediaDescriptor (not set at all, nor true, nor false), then trying to store it produces an error and does *not* overwrite the existing document.

This is what my macro tries to show you.


If you load a document from an URL, and then try to store it to the same URL, obviously not setting Overwrite at all will overwrite the document: storing a document to the same URL from where it was loaded is *overwriting* the state before the last save operation. Setting Overwrite to true is the same as not setting at all.

But setting Overwrite to false must produce an error: storing a document to the same URL from where it was loaded *must* overwrite it, it's something logical.

> The definition in 
> http://www.openoffice.org/api/docs/common/ref/com/sun/star/document/MediaDescriptor.html 
> says that the default value is FALSE, implying that this should give an error.

The meaning of this sentence:

"overwrite any existing file 
For storing only: overwrite any existing file, default is false, so an error occurs if the target file already exists."


is that when you try to store a document to an URL, and this URL points to *another* document, then the application will not try to overwrite the existing file, it will throw an exception.

When you store the document to the same URL where it was loaded, storeAsURL() is the same as store(), and obviously saving the document overwrites it. If you set Overwrite to False an exception will be thrown. Setting Overwrite to True is redundant.

http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Storing_Documents

"The XStorable offers the methods store(), storeAsURL() and storeToURL() for storing. The latter two methods are called with a media descriptor.

The method store() overwrites an existing file. Calling this method on a document that was created from scratch using a private:factory/... URL leads to an exception.

The other two methods storeAsURL() and storeToURL() leave the original file untouched and differ after the storing procedure. The storeToURL() method saves the current document to the desired location without touching the internal state of the document. The method storeAsURL sets the Modified attribute of the document, accessible through its com.sun.star.util.XModifiable interface, to false and updates the internal media descriptor of the document with the parameters passed in the call. This changes the document URL."


The documentation doesn't explain that

oDoc.storeAsURL( oDoc.getLocation(), Array() )

is the same as oDoc.store()

precondition: oDoc.hasLocation() returns true.

Created attachment 80171 [details]
Example when storeAsURL() is the same as store()

You say you don't understand my (rather simple) program. The line which gives an error is clearly marked.

The line giving the error is Doc.StoreAsURL(FileURL,EmptyArray). Because the array is empty, the file should not be overwritten, as the default is FALSE. The next line fails to store (as I'd expect) because the file's already there.

At the end of your explanation you say  that StoreAsURLto the original URL is the same as Store(). This may well be true, but it's not in the XStorable definition, which is what I was going on. It's also not the same as the behaviour of OOWriter using the "Save As" menu item. Try opening a document, clicking "Save As", and choosing the original file name. It (quite rightly in my view) fails. So in this case "SAVE AS" to the original file is NOT the same a "Save", which (equally rightly) overwrites.

So, in my view, it's either a documentation bug or a bug in StoreAsURL.

Matters aren't helped by http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Handling_Documents which says under "Overwrite": "boolean. For storing only: overwrite existing files with the same name, default is true, so an com.sun.star.io.IOException occurs if the target file already exists. If the default is changed and the file exists, the UCB throws an exception. If the file is loaded through API, this exception is transported to the caller or handled by an interaction handler." which says that the default is TRUE.

(In reply to comment #7)
> You say you don't understand my (rather simple) program. The line which
> gives an error is clearly marked.

May be I wasn't clear while expressing myself (I'm no native English speaker). You example isn't clear to me, as an example of the Description of the bug (it's using storeAsURL in the wrong way).


> The line giving the error is Doc.StoreAsURL(FileURL,EmptyArray). Because the
> array is empty, the file should not be overwritten, as the default is FALSE.
> The next line fails to store (as I'd expect) because the file's already
> there.

But all this is because you are mixing store() with storeAsURL(). You're program logic should be:

Dim oDoc as Object
oDoc = ...
If oDoc.hasLocation() Then
   oDoc.store()
Else
   oDoc.storeAsURL(sURL, aMediaDescriptor)
End If
 
> At the end of your explanation you say  that StoreAsURLto the original URL
> is the same as Store(). This may well be true, but it's not in the XStorable
> definition, which is what I was going on. 

It isn't explained explicitly, but it can be deduced by reading all the other methods:

- use store() if the document has a location
- use storeAsURL() if the document has no location

> It's also not the same as the
> behaviour of OOWriter using the "Save As" menu item. Try opening a document,
> clicking "Save As", and choosing the original file name. It (quite rightly
> in my view) fails. So in this case "SAVE AS" to the original file is NOT the
> same a "Save", which (equally rightly) overwrites.

In the GUI things are different: the error box telling that the file already exists is not triggered by an exception caused by storeAsURL(), but by the way the Save dialog is implemented internally (if the document has a location, and there is a file with the same location, it shows an error box, it does not even try to save it).


> So, in my view, it's either a documentation bug or a bug in StoreAsURL.

In the case of the abstract interface description, this could be an enhancement.

> Matters aren't helped by
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/
> Handling_Documents which says under "Overwrite": "boolean. For storing only:
> overwrite existing files with the same name, default is true

In this case, this is an error, the default behavior is false: files are *not* overwritten by default. This documentation should be corrected.

Firstly, I didn't realise that English was not your first language. You certainly write it very well. Far better than I could do in your language (whatever that is).

I think that neither of us is quite understanding the other. And possibly we are both understanding different things from the same documentation!

Exactly what does the Overwrite property mean when using StoreToURL or StoreAsURL? Is it intended to mean:

A) (if TRUE) that even if the file exists, it will be overwritten, and (if FALSE), that it will never be overwritten and produce an error. That seems to be what your program demonstrates. Or 

B) is the value stored with the file, so that if it is FALSE the file cannot be overwritten? This seems to be the same as ReadOnly, and therefore redundant.
 
So I have assumed that (A) is correct.

But my original comment was about the behaviour of StoreAsURL when a null array is given as parameter. In this case, the definition in XMediaDescriptor says explicitly "For storing only: overwrite any existing file, default is false, so an error occurs if the target file already exists." But my program shows that this doesn't happen: the file is overwritten without an error. 

In my opinion, that is the correct behaviour: the default should never destroy information. That's why I think it's an OO bug. If the OO teams think that the current behaviour is correct, the documentation should be changed to reflect reality.

Anyway, I now know that I should always set the Overwrite property as I want to, and trap the error if it's set to FALSE.

This seems to have gone very quiet. Is anyone there?

(In reply to Ariel Constenla-Haile from comment #8)

Ariel,

I haven't heard anything about this for 6 months. Are you still alive (I hope so)?

If you didn't understand my comment, please let me know and I'll try to be clearer. I know how difficult it is to write clearly enough for someone who doesn't have English as a first language.

(In reply to ptoye from comment #11)
> (In reply to Ariel Constenla-Haile from comment #8)
> 
> Ariel,
> 
> I haven't heard anything about this for 6 months. 

Oh sorry, this went out of my radar.

> Are you still alive (I hope so)?

yes, I am :)
Note that the bug is not assigned to me, this means I just took at look at it, but didn't plan to work on it.

> If you didn't understand my comment, please let me know and I'll try to be
> clearer. I know how difficult it is to write clearly enough for someone who
> doesn't have English as a first language.

I am no longer working with AOO core code, and I have no plans to do so in the foreseeable future.
But the bug is assigned to "AOO issues mailing list", anyone reading that list can take care of solving this bug.

(In reply to Ariel Constenla-Haile from comment #12)

> > Are you still alive (I hope so)?
> 
> yes, I am :)

Great :)

> Note that the bug is not assigned to me, this means I just took at look at
> it, but didn't plan to work on it.
> 
> 
> I am no longer working with AOO core code, and I have no plans to do so in
> the foreseeable future.
> But the bug is assigned to "AOO issues mailing list", anyone reading that
> list can take care of solving this bug.
But who's on this list - how can I find out if it's being looked at or put into the waste bin?