Possible bug with Copy.vi

[AMP12]

Don't know if this is a legitimate bug or not, but has anyone recieved an error while using the Copy.vi from the Advanced Files Functions palet?

As I'd expect, if I try to copy a single file from C:\Folder_A\Folder_B\Folder_C to the next lower folder, C:\Folder_A\Folder_B it works fine. But I've come across a situation where if I try to copy the entire folder from C:\Folder_A \Folder_B\Folder_C to folder C:\Folder_A\Folder_B I get an error 7 from the Copy.vi.

Additionally I've observed that somehow in copy process before error-ing out, the first file in source folder (Folder_C) gets deleted. No copies take place.

Now if I copy the entire folder from C:\Folder_A\Folder_B\Folder_C to C:\Folder_A everything works fine, for both the single file and the entire folder. Why am I getting this Error 7: file not found here?

[altenbach]

Can you attach a small VI that demonstrates the problem?

[AMP12]

Shoot!! I meant to but forgot. I will, but the guts of the vi is the copy.vi. Will attach it in the morning.

[AMP12]

The Copy Bug.vi is the one I posted about above.

Before attaching the exact sample I was using, I quickly threw together a I simple one without my custom VI and got different results (attached as Copy Bug2.vi).  When I perform the copy entire folder from C:Folder_A/Folder_B/Folder_C to C:Folder_A/Folder_B, I get error 10 for Duplicate path.  Again, why?

It works fine if I set the target path to C:Folder_A.  Both situations don't like copying to the next higher folder, but flag different errors, and are fine with moving two or more folders up.  Can anyone duplicate this situation or is it just me?  Seems like a bug...

[altenbach]

---

@AMP12 wrote:

But I've come across a situation where if I try to copy the entire folder from C:\Folder_A \Folder_B\Folder_C to folder C:\Folder_A\Folder_B I get an error 7 from the Copy.vi.

---

Preliminary analysis:

If you copy from C:\Folder_A \Folder_B\Folder_C to folder C:\Folder_A\Folder_B. you are trying to create a new

C:\Folder_A \Folder_B\Folder_C

which of course already exists, so I understand that there could be a problem and there should be an error. However, error 7 is a bit strange. I'll think a bit more....

[billko]

This might be an OS-dependent thing?  I think I recall issues copying big chunks of files from one place to another on a network drive in Windows?  I don't know if it's relevant here, though...

[AMP12]

Billko,

That doesn't seem to be the case, as I developed the VI over a couple different networks and all worked fine.  Speed became an issue, but overall functionality did not.

Altenbach,

I agree with you preliminary analysis now that it is right in front of my nose.  So now your point about error 7 (file not found) really becomes the question. When using the Advanced File Function's C&P, error 10 (duplicate path) makes complete sense.

My sub VI in Copy Bug.vi steps into the Advanced File Function's C&P right away and flags an error 7, then never sees the rest of the code, so it essentially is doing the same thing as above.  I have no idea why it simply wouldn't be error 10 as well.  An further thoughts or opinions are welcome.

[billko]

I think it might be because of the way copy.vi works:

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.

I think the problem is with the last sentence.  Essentially you are trying to copy the folder over itself, so it inserts a copy INSIDE of itself.  The error 7 could conceivably be because it tried to copy the first file inside the duplicate folder before the file was completely copied.  That file doesn't "exist" yet.

[edit] It could also be because it deleted the first file in preparation for copying it over itself, if it actually tried to overwrite itself instead of placing the folder inside itself.

It would be interesting to see the fallout from your aborted copy...

[rolfk]

---

@billko wrote:

[edit] It could also be because it deleted the first file in preparation for copying it over itself, if it actually tried to overwrite itself instead of placing the folder inside itself.

It would be interesting to see the fallout from your aborted copy...

---

I think this is actually the problem although not exactly in the way you describe it. LabVIEW doesn't delete the file but instead creates it. This is translated by the OS to truncate the original file and now when LabVIEW tries to open the original file to read from it this fails since the file is already opened for write access by someone else (the previous creation for the copy target). This should of course result in the error code "file already open" but that would be almost as misleading. I'm pretty sure that copying onto itself wasn't even possible in earlier LabVIEW versions, but it is possible that with the huge file IO overhaul at around LabVIEW 8.0 something like this slipped into.