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
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?
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
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 )
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.
Will debug. Please tell me, I don't remember, how to quickly and easily create and invoke such Basic code, though;)
sorry to interupt, but i found the bug using URL like path's then is tried also the windows path's
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
and where do I paste that code, and how do I invoke it?
look at menu : tools > macros > Basic macros paste the code in the standard module press F5 to run it
Debugging this now. In the sbmi.dll!SbRtl_FileCopy() at least the parameters look fine.
The code from comment #7 works for me on XP, which is the (virtual) machine where I usually debug...
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.
individual file copying was never broken , please place some files in a directory en copy to a other
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?
> individual file copying was never broken OK, good, it was comment #7 that mislead me.
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.
I mean, I get General Error dialog windows and none of the "True" (or "False", I guess) from the print statements. Interesting...
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"
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?)
the sample from comment #1 works for me with the latest build
(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
Fernand, in which version of LibreOffice or OpenOffice.org (and from which vendor) did you see a different behaviour?
so far not(yet) in OO 3.3 firsttime in LibreOffice 3.4.0 DEV300m103 (Build:4)
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++
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.)
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.
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 )
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