DirCopy() does not work at all

[SnakeDoc]

I'm working in AutoIT 3.3.6.1 to script a basic task I'll have to repeat on 50ish workstations.

I need to copy a directory and it's subdirectories and files (recursively) to a network share as a backup. For some reason, DirCopy() does not work at all.

I've tried running it on several different directories (thinking permissions issue, I'm Domain Admin account), tried doing a RunAs (again thinking permissions), and also put the

#RequireAdmin 

tag to force the program to run on an elevated account. Nothing has worked. I can't even get it to copy empty directories.

DirCopy(@DesktopDir & "\SAMPLE\TEST1", @DesktopDir & "\SAMPLE\TEST2", 0)

Edited June 25, 2013 by SnakeDoc

[willichan]

Worked perfectly for me.  I am using 3.3.8.1.  I am not aware of any change to DirCopy between the two versions.

[water]

What is the return value of DirCopy?

$iReturn = DirCopy(@DesktopDir & "\SAMPLE\TEST1", @DesktopDir & "\SAMPLE\TEST2", 0)
MsgBox(0, "", $iReturn)

[SnakeDoc]

OK guys I think I got this one figured out.

It's broken/bad Docs (yes some of us actually read the docs!!!!!)

From the docs on DirCopy:

 

If the destination directory structure doesn't exist, it will be created (if possible).

 

This implies that if flag is set to 0 (default) it will simply copy the files/subdirectories into the destination directory. However this is not the case. If you set flag to 1, then my above code-line works.

Basically DirCopy() seems to only allow flag 0 when the destination directory does not already exist. This should be revised in the docs please... or perhaps the function updated since this is not the expected behavior for most I think... personally I was trying to concat a bunch of backups to a single directory, which now I realize is not possible in AutoIT. I"ll need to have DirCopy() create a new subdirectory for each backup copy.

 

EDIT: @water - return value is 0 (failed). 

Edited June 25, 2013 by SnakeDoc

[Mat]

I'm getting very annoyed at people asking questions in multiple places. You really are wasting my time.

I don't mind if you ask in one place, don't get an answer, so try somewhere else. But to ask in both places at the same time and not even link to it is just rude.

[willichan]

It's broken/bad Docs (yes some of us actually read the docs!!!!!)

 

Basically DirCopy() seems to only allow flag 0 when the destination directory does not already exist. This should be revised in the docs please... or perhaps the function updated since this is not the expected behavior for most I think... personally I was trying to concat a bunch of backups to a single directory, which now I realize is not possible in AutoIT. I"ll need to have DirCopy() create a new subdirectory for each backup copy.

 

That is not correct.  I copied your 1-line code, and created the source directory with a few files in it.  It ran perfectly with the 0 flag, whether the target folder existed or not.

The docs are correct.

[SnakeDoc]

You know this is the third topic I've read today on this forums where the word "Annoyed" has been used from a MVP, Moderator, or Developer. This isn't good community building guys, it tears it down and makes people not want to use this community. As you can see, this was my first post here, and I'm unlikely to return now.

I posted in both places because I was afraid I was be chastised here for such a simple problem. That and the SO community really isn't big on AutoIT, and therefore I thought I wouldn't get an answer there, so I posted here. 

[SnakeDoc]

@willichan thanks for the constructive feedback.

I'm replicating this 100% of the time. Is there a way I can submit it to someone for review? My environment is XP SP3, AutoIT 3.3.6.1

[willichan]

You might try downloading the current version.  As I said before, I don't think there were any changes to DirCopy(), but I don't know for sure.

I think the problem is outside of AutoIt though.  You might have some kind of software interfering.  Try changing the target location and see what happens.  You mentioned saving to a network location.

If you have xcopy, you can try it from a command line and see if it succeeds.  It might give you a clue to where the real problem lies.

[SnakeDoc]

Hmm... I have already tried several different source and destination directories (both with spaces and without spaces in the path name) both on network shares and on local disk... same thing. I can only get DirCopy() to work when I either use 1 (overwrite) or have a new directory name as the destination that does not already exist.

Good suggestion with xcopy, only problem is I'm supporting Windows 2000 through Windows 7 for this script, meaning xcopy isn't available on 2/3's of my install base. 

Just so I'm clear, this is my file structure:

This source dir will be copied from several workstations then all concated to a single destination directory (dst). So there will be multiple "src" directories with teh same name, but each subdirectory underneith that is unique (dir1, dir2, etc).

src1

   dir1

      somefile.txt

      somefile2.txt

   dir2

      somefile453.txt

src2

   dir3

      somefile.txt

      somefile2.txt

   dir4

      somefile453.txt

src3

   dir5

      somefile.txt

      somefile2.txt

   dir6

      somefile453.txt

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

dst

   dir1

      somefile.txt

      somefile2.txt

   dir2

      somefile453.txt

   dir3

      somefile.txt

      somefile2.txt

   dir4

      somefile453.txt

   dir5

      somefile.txt

      somefile2.txt

   dir6

      somefile453.txt

 

The problem is "dst" directory will already exist by the time "dir2" needs to be copied to it. So using the flag 1 is a no-go... it must be flag 0, but then it fails.

[SnakeDoc]

Ok just updated to latest AutoIT 3.3.8.1 and same thing. 

Could this be an XP issue?

[Mat]

You know this is the third topic I've read today on this forums where the word "Annoyed" has been used from a MVP, Moderator, or Developer. This isn't good community building guys, it tears it down and makes people not want to use this community. As you can see, this was my first post here, and I'm unlikely to return now.

I posted in both places because I was afraid I was be chastised here for such a simple problem. That and the SO community really isn't big on AutoIT, and therefore I thought I wouldn't get an answer there, so I posted here. 

 

You are right, the AutoIt community isn't really on SO. In fact there are probably only 2 people actively answering questions there. As a result, I go out of my way to make sure I do answer questions (a lot more than I do on the forums). If you are going to ask in both places, you are wasting somebodies time, so don't make out as though I'm the bad guy in all this.

You also happen to be coming in at the wrong moment. There was recently a user who asked 8 questions on both sites in the space of a few days, of which I answered 5.

For everyone elses reference, I have already verified what SnakeDoc is saying, and actually reported this as a helpfile error >here. The helpfile is definitely misleading in this case.

xcopy is deprecated under vista+ just as an extra note.

If you don't need to copy nested folders then you could just use: FileCopy("SOURCE*", "DEST", 8)

[SnakeDoc]

Mat I thank you for taking the time to flag this as an issue.

Regarding the rudeness earlier, I can see where you were coming from and I was not aware of the previous issues. Please don't assume every user coming here is a complete idiot, I am a professional software engineer and systems administrator with a decade of experience (just not in AutoIt). I know how to use forums.

Starting off the way you did, it really rubs people the wrong way and causes a lot of friction on this forums. If you examine my post timestamps, you can see I posted to SO first, then realized there was no community there to help me, so I proceeded to post here. I chose not to post here initially because of other aggressive posts on this forums (a lot coming from the same Mod actually). 

Anyways, I thank you for your help and for filing this "bug". 

I do need to copy nested folders however my example above lacked that aspect, my apologies. This means FileCopy() won't do either... I'll need to figure out some other way. I'll likely have to drop to another language (probably java since it's already installed on all our systems) for the directory copying portion before returning to the script to do the rest of the tasks. 

[AdmiralAlkex]

xcopy is deprecated under vista+ just as an extra note.

Does it say that it's deprecated in Vista? 7 or 8 doesn't, so it's probably safe to use. Maybe they just isn't going to add new features to it or something.

[Mat]

Does it say that it's deprecated in Vista? 7 or 8 doesn't, so it's probably safe to use. Maybe they just isn't going to add new features to it or something.

It does say it's deprecated on vista, and a quick Google shows that you are right: the deprecation message doesn't appear in 7 or 8 apparently robocopy was going to replace it.

[guinness]

You might try downloading the current version.  As I said before, I don't think there were any changes to DirCopy(), but I don't know for sure.

Change-log would specify any changes made.

[willichan]

xcopy is deprecated under vista+ just as an extra note.

 

I only suggested xcopy since the OP is on XP, and it is the simplest command line approximation to what DirCopy() does.  If there is some external element that is interfering with DirCopy, then it would most likely also have the same effect on xcopy.

I still find alot of my old DOS utilities useful on occasion.

[SnakeDoc]

@willichan I do not believe there is any external element interfering with DirCopy(), as I get the same behavior on different machines (all XP). I believe it's the design of DirCopy() and it's doing exactly as it was written to do. It's just either the documentation needs updating to reflect it's true behavior (and not leave any ambiguity) or the function itself needs updating to match the documentation (for expected behavior).