Download it now!
Bug 37319 - Filecopy function no longer works as before
Summary: Filecopy function no longer works as before
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
3.4.0 Beta5
Hardware: Other Windows (All)
: high critical
Assignee: Noel Power
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-18 07:15 UTC by Fernand
Modified: 2011-05-20 08:06 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fernand 2011-05-18 07:15:37 UTC
When copying all files from one directorie to a other "filecopy" no longer works

Trie the macro who made some directories and then trie to copy between them
using the Filecopy function
sub filecopytest
mkdir "c:\copytest1\"
mkdir "c:\copytest1\copytest11"
print fileexists("c:\copytest1\copytest11")
mkdir "c:\copytest2\"
mkdir "c:\copytest2\copytest22"
print fileexists("c:\copytest2\copytest22")
filecopy("c:\copytest1", "c:\copytest2")' gives a "general error"
end sub

the new maded directorieare empty, but also with somle files init "filcopy no longer works as before

BLOCKS several extentions an applicatios who use "filecopy" to copy or replace all the files in a directory
Comment 1 Petr Mladek 2011-05-19 02:33:15 UTC
It blocks extensions => it is not the core functionality => it must not block the 3.4.0 release => reducing severity a bit.

Though, I agree that we should fix it relatively soon => listed in the most annoying bugs.

Noel, could you please have a look?
Comment 2 Laurent Godard 2011-05-19 02:49:49 UTC
i do not agree on the logic of Petr

LibreOffice is a plateform extension developper should be confident in; Most enterprise deployement are also based on custom extension.

It is a matter of credibility regarding regressions
Comment 3 Noel Power 2011-05-19 03:11:36 UTC
this appears to be a windows only bug, cc'ing tor who might be able to help debugging 
tor, do you have some time to help ?  - meanwhile I am going to try and get a windows build ( but that will take me time on virtual machine )
Comment 4 Michael Meeks 2011-05-19 03:58:30 UTC
code is in: basic/source/runtime/methods.cxx /RTLFUNC(FileCopy)/

I assume 'hasUno' is always true (why do we still have those old code-paths for the other cases I wonder).

It would be interesting to know if it works with URLs instead of C:\paths - might help isolate it a bit more, otherwise I guess the problem lurks in ucb/source/ucp/ somewhere, or in the osl code it calls on windows.
Comment 5 Don't use this account, use tml@iki.fi 2011-05-19 04:21:29 UTC
Will debug.

Please tell me, I don't remember, how to quickly and easily create and invoke such Basic code, though;)
Comment 6 Fernand 2011-05-19 04:54:25 UTC
sorry to interupt,
but i found the bug using URL like path's then is tried also the windows path's
Comment 7 Laurent Godard 2011-05-19 05:00:08 UTC
here is sample macro code


Sub Main

    srcFile = "C:\fileOne.txt"
    destFile = "C:\fileTwo.txt"

    ' test copying with paths
    fileCopy srcFile, destFile

    ' test copying using URL
        destFile = "C:\fileThree.txt"
    fileCopy convertToURL(srcFile), convertToUrl(destFile)

End Sub
Comment 8 Don't use this account, use tml@iki.fi 2011-05-19 05:30:55 UTC
and where do I paste that code, and how do I invoke it?
Comment 9 Laurent Godard 2011-05-19 05:39:32 UTC
look at menu :  tools > macros > Basic macros
paste the code in the standard module
press F5 to run it
Comment 10 Don't use this account, use tml@iki.fi 2011-05-19 06:49:18 UTC
Debugging this now. In the sbmi.dll!SbRtl_FileCopy() at least the parameters look fine.
Comment 11 Don't use this account, use tml@iki.fi 2011-05-19 06:58:49 UTC
The code from comment #7 works for me on XP, which is the (virtual) machine where I usually debug...
Comment 12 Don't use this account, use tml@iki.fi 2011-05-19 07:07:12 UTC
The code from comment #7 works for me also on Windows 7 (in the beta 5 build). So I guess it indeed is the case of copying the contents of directories (as mentioned in the initial comment), not individual files, that breaks? Will debug that.
Comment 13 Fernand 2011-05-19 07:17:07 UTC
individual file copying was never broken ,
please place some files in a directory en copy to a other
Comment 14 Don't use this account, use tml@iki.fi 2011-05-19 07:20:13 UTC
Fernand, what do you mean when you say 'gives a "general error"' ? I don't see any error message.

What I see when running Fernand's sample code is:

At the second "print", c:\copytest1 contains an empty copytest11 directory. c:\copytest2 contains an empty copytest22 directory. As expected.

But then after one clicks ok to the message, the end result is that c:\copytest2 contains only an empty copytest11 directory. I.e. the filecopy function has made the contents of c:\copytest2 an exact copy of the contents of c:\copytest1.

What was expected to happen? I see two possible interpretations:

1) c:\copytest2 should contain a copy of the contents of c:\copytest1, in addition to its previous contents. I.e. it should contain the empty copytest11 and copytest22 directories. This would correspond to the Unix command
cp -r /copytest1/* /copytest2

2) c:\copytest1 itself should be copied into c:\copytest2 in addition to its previous contents. I.e. c:\copytest2 should still contain the empty directory copytest22, and in addition a directory copytest1 and in that an empty directory copytest11. This would correspond to the Unix command
cp -r /copytest1 /copytest2

Which one is the documented behaviour? Does the documented behaviour match what earlier versions did?
Comment 15 Don't use this account, use tml@iki.fi 2011-05-19 07:21:05 UTC
> individual file copying was never broken

OK, good, it was comment #7 that mislead me.
Comment 16 Don't use this account, use tml@iki.fi 2011-05-19 07:25:58 UTC
Interesting, when I run the code in the initial comment on Windows 7, it works as I said in comment #14. But when I run it on XP, I indeed get the highly useful "General Error" dialog, several times.
Comment 17 Don't use this account, use tml@iki.fi 2011-05-19 07:39:49 UTC
I mean, I get General Error dialog windows and none of the "True" (or "False", I guess) from the print statements. Interesting...
Comment 18 Fernand 2011-05-19 07:48:26 UTC
before: the content of the "last" (left)directory  was copied to "last" (right)directory .
filecopy("c:\cdir1\cdir2\cdir3\" , "f:\fdir1\fdir2\")
here the content of "cdir3" was copied to "fdir2"
Comment 19 Don't use this account, use tml@iki.fi 2011-05-19 07:57:17 UTC
Ignore my last two comments (comment #16 and comment #17), I had copy-pasted wrongly and had a syntax error;) (Hopefully we have some bug report open about the useless "General Error" message n such a case?)
Comment 20 Noel Power 2011-05-19 08:21:04 UTC
the sample from comment #1 works for me with the latest build
Comment 21 Noel Power 2011-05-19 08:24:37 UTC
(In reply to comment #19)
> Ignore my last two comments (comment #16 and comment #17), I had copy-pasted
> wrongly and had a syntax error;) (Hopefully we have some bug report open about
> the useless "General Error" message n such a case?)

No, I don't believe this has been reported, I have opened bug #37370
Comment 22 Don't use this account, use tml@iki.fi 2011-05-19 09:10:05 UTC
Fernand, in which version of LibreOffice or OpenOffice.org (and from which vendor) did you see a different behaviour?
Comment 23 Fernand 2011-05-19 09:14:04 UTC
so far not(yet) in OO 3.3

firsttime in
LibreOffice 3.4.0 
DEV300m103 (Build:4)
Comment 24 Don't use this account, use tml@iki.fi 2011-05-19 12:17:47 UTC
Still debugging, adding this stack trace here in case I forget where I was:

>	ucpfile1.dll!fileaccess::shell::copy(long CommandId=0x00000139, rtl::OUString srcUnqPath={...}, rtl::OUString dstUnqPathIn={...}, long NameClash=0x00000001)  Line 1367	C++
 	ucpfile1.dll!fileaccess::BaseContent::transfer(long nMyCommandIdentifier=0x00000139, const com::sun::star::ucb::TransferInfo & aTransferInfo={...})  Line 1158 + 0x62 bytes	C++
 	ucpfile1.dll!fileaccess::BaseContent::execute(const com::sun::star::ucb::Command & aCommand={...}, long CommandId=0x00000139, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & Environment={...})  Line 409 + 0x14 bytes	C++
 	ucb1.dll!UniversalContentBroker::globalTransfer()  + 0x559 bytes	C++
 	ucb1.dll!UniversalContentBroker::execute()  + 0x1cd bytes	C++
 	ucbhelper4MSC.dll!ucbhelper::Content::transferContent(const ucbhelper::Content & rSourceContent={...}, ucbhelper::InsertOperation eOperation=InsertOperation_COPY, const rtl::OUString & rTitle={...}, const long nNameClashAction=0x00000001)  Line 1587 + 0x44 bytes	C++
 	fileacc.dll!io_FileAccess::OFileAccess::transferImpl(const rtl::OUString & rSource={...}, const rtl::OUString & rDest={...}, unsigned char bMoveData=0x00)  Line 353 + 0x38 bytes	C++
 	fileacc.dll!io_FileAccess::OFileAccess::copy(const rtl::OUString & SourceURL={...}, const rtl::OUString & DestURL={...})  Line 365	C++
 	sbmi.dll!SbRtl_FileCopy(StarBASIC * pBasic=0x065f21e8, SbxArray & rPar={...}, unsigned char bWrite=0x00)  Line 558 + 0x81 bytes	C++
Comment 25 Don't use this account, use tml@iki.fi 2011-05-19 12:23:48 UTC
The code actually removes the target directory completely if it exists, it doesn't remove the contents of the directory. Only after that it starts copying the source directory into a new directory with the new name. The distinction might seem small, but it is significant. The code in question is http://opengrok.libreoffice.org/xref/libs-core/ucb/source/ucp/file/shell.cxx#1403 , which has been there since 2001...

(But yeah, sure it is possible that the code has worked in other places differently in earlier versions, and this particular code path hasn't been invoked. Anyway, I will test myself if it really is so that the sample code worked differently in earlier versions of OOo.)
Comment 26 Don't use this account, use tml@iki.fi 2011-05-19 12:37:01 UTC
Ha! I have an installation of OpenOffice.org 3.3.0 from Oracle in a saved snapshot in a virtual machine. Guess what, it behaves exactly as LibreOffice 3.4 in this test case.

I also have an installation of LibreOffice 3.3.2 in another snapshot in the virtual machine. Same story there.

So I am tempted to resolve this bug as NOTABUG unless the reporter can point to an *exact* downloadable previous version of LibreOffice or OpenOffice.org where the behaviour has been different.
Comment 27 Noel Power 2011-05-20 02:01:08 UTC
closing this as fixed, that is the general error is no longer raised on windows when running the filecopy function. 
Now regarding the behaviour of the filecopy function, indeed it does completely remove any existing contents of the target directory (personally that seems wrong to me)  othoh this behaviour is present at least since Openoffice2.4 ( which I have a copy of and also tested with )
Comment 28 Fernand 2011-05-20 08:06:57 UTC
i just instaled 
LibreOffice 3.4.0 
OOO340m1 (Build:11)
and the filecopy behaved again like it always was in OO and <LO
now i (you can) run:
filecopy("c:\copytest1", "c:\copytest2\copytest22")
the files contained in \copytest1 are copied to \copytest22

so in LibreOffice 3.4.0 DEV300m103 (Build:4) it was not working
      LibreOffice 3.4.0 OOO340m1 (Build:11) it is working

sory for the fuss and lost time and energy, but i trie to run all our working code/extensions on a regular base to detect as soon as possible a regression. Here it was a false alarm
Sory