Copy bug

[Matthew_Kelton]

So, while I was trying to help someone in a thread, I uncovered what I consider to be a bug in LabVIEW's Copy primitive.

If you are specifying a folder to be copied, LabVIEW will copy the files and directories in the folder specified.  However, you get two different behaviors depending on whether the destination location exists or not.

If the destination does not exist, LabVIEW creates the folder.  The files and diretcories of the source are copied into the created folder.  For example, if I copy c:\test1 to c:\test2 and c:\test2 doesn't exist, LabVIEW creates c:\test2 and copies the files and directories from c:\test 1 into c:\test2.  This is the behavior I expect.

If the destination folder does exist, LabVIEW creates a folder in the destination directory with the name of the subdirectory you are copying. For example, I copy c:\test1 to c:\test2 and c:\test2 exists, LabVIEW creates c:\test2\test1 and copies the contents of c:\test1 into c:\test2\test1.  I do not expect this behavior.

As you can see (I have attached a zip file with some dummy files and an example VI for demonstration), if you run the VI twice in a row with c:\test2 not existing at the beginning, you do not get the same results.  The first time the files go into c:\test2, the second time, they go into c:\test2\test1.

Since the copy function supports creating the directory, I can specify c:\test2\test1 as my destination if that is my desired destination.  As it stands now, the user either has to delete the destination directory (which may not be desirable) or write their own code to work around this problem.

Message Edited by Matthew Kelton on 12-09-2008 12:26 PM

[Andrey_Dmitriev]

you wrote: "If the destination does not exist, LabVIEW creates the folder.  The files and diretcories of the source are copied into the created folder.  For example, if I copy c:\test1 to c:\test2 and c:\test2 doesn't exist, LabVIEW creates c:\test2 and copies the files and directories from c:\test 1 into c:\test2.  This is the behavior I expect.

If the destination folder does exist, LabVIEW creates a folder in the destination directory with the name of the subdirectory you are copying. For example, I copy c:\test1 to c:\test2 and c:\test2 exists, LabVIEW creates c:\test2\test1 and copies the contents of c:\test1 into c:\test2\test1.  I do not expect this behavior. " 

from LabVIEW Help:

Copy Details

This function copies the original file or directory and renames the copy with the name that you specify in the last element of the target path. If target path is the path to an existing file, this function returns a Duplicate Path error. If target path is the path to an existing directory, the function places the new file or directory inside the existing directory using the original file or directory name.

For example, if you copy the directory c:\app to d:\app2, the function creates a new directory d:\app2 with the same contents as c:\app. The second time you copy the directory, the function creates a new subdirectory d:\app2\app and places the contents of app there. The third time you copy the directory, the function returns a Duplicate Path error.

Its not a bug, its a feature, isn't? Or I missing something?

Andrey.

[Hillman]

Hi Mathhew,

Thanks for your post and I hope your well.

I have to agree with Andrey, I beleive this to be a feature rather than a bug. 

Mathew, are you saying you beleive in the case when the folder exists, that LabVIEW should place the contents of the copied folder into the folder without creating a sub-folder?

Thanks for discussing this feature/bug,

[Matthew_Kelton]

Yes.  Why should the VI execute differently, escpecially when it supports creating directories?  I can easily create the behavior of VI when c:\test2 already exists by specifying c:\test2\test1 as my destination.  As it stands now, for me to copy c:\test1 into c:\test2 consistently, I either have to create the directory c:\test2 (which in the case of the thread I was working with, it is undesirable to have c:\test2\test1), or I have to delete c:\test2 before I do the copy.  This can be undesirable if I have files besides those of test1 in the directory structure.

I see no reason why the Copy function cannot behave consistently regardless of whether the folder exists, especially when I can specify c:\test2\test1 as the destination and achieve the same results.  The only way to obtain consistent behavior that c:\test1 always goes into c:\test2 is to write your own code and copy each file individually.

[Andrey_Dmitriev]

Matthias, yes, I've got also troubles with this behaviour. You should copy the files individually (or use OpenG copy in some cases). So, this is pretty unconvinient feature. But not bug, because at least this behaviour documented (but produced additional code for pretty simple thing, you're right).

Andrey.

[Coq_Rouge]

It is a bug. If I use the copy and is doing a dir copy I expect two things.  If overwrite is false and the target dir exist an error is the correct event. If overwrite is true I exspect every thing to be copied or overwritten. It is all or nothing. Not I copied your files, but I did it with a little surprise you (or your program) will find out then the folder is opened

[Hillman]

Hi Guys,

Thanks for continuing to discuss this inconvenient feature. Do you feel worthy that we should consider altering this in a future version? It does seem rather straight forward.. and Im not sure what benefits the current function would offer anyone.

If we compare this with windows, if I copy a folder from my desktop into a new folder, the first time it creates it - thats good. Then second time it asks to replace or not bother. This is where LabVIEW decides the user shouldn't lose data (maybe) and decides to create a subfolder. If the user had other data in 'test2' wouldnt the user (without any choice) lose everything! This is maybe why the user currently has to delete is in the code - as in the user has released data will be lost...

You could also make a product suggestion,

http://digital.ni.com/applications/psc.nsf/default?OpenForm

The more requests for the same feature tends to help the team notice features that should be / are request by our users. 

Any thoughts?

[Matthew_Kelton]

In the current versions of LabVIEW, there is an input to overwrite files.  If the user doesn't set this to True, then they will get an error with the copy function.  If they set it to True, then it will overwrite any existing files, much like Windows does.

As you said, Windows copy doesn't function this way, and at least to me, it makes no sense for the LV copy function to behave in this manner, especially when the user can easily get the result if that is their desired result.  With the code I posted, it only does it once. After creating c:\test2\test1, the copy will overwrite c:\test2\test1, not create c:\test2\test1\test1 or "c:\test2\test1 Copy".  The user wouldn't lose data in c:\test2 unless a file with the same name existed in c:\test1.

So, the user has a choice by specifying the overwrite boolean, and the current method only works once before an overwrite must occur.  I made the product suggestion before I realized that it behaved differently if the directory didn't exist.  Honestly, just because the copy function is documented to work this way doesn't mean it should work this way.

[GITA_A]

Hi Matthew,

         Thanks for reporting this behaviour of a copy function even i found this problem in my application but how can we overcome by this issue and i could open your attached Zip file in your first reply. It is showing an unknown format as shown in the attachment.

[User002]

Matthew,

I completely agree with your point on how the copy function should work. I think it would be worthwhile to put in a request to NI to change this feature via the link provided by Hillman.

Oh yeah, you may want to reword that last sentence. I'm guessing that you really meant that the copy function should be changed.

---

Matthew Kelton wrote:

Honestly, just because the copy function is documented to work this way doesn't mean it should work this way.

---

 If something is documented to work as such, it should work like that or else the documentation is wrong and misleading.

Message Edited by brainhead on 12-11-2008 01:18 AM