I have a Windows command-line .bat file that I use as a simple backup mechanism. I have just ported it to my new Vista Home Premium system, and when the xcopy command tries to create corresponding directories on the backup drive E: I get two kinds of error messages:
Unable to create directory - E:\CWG-PC\Users\All Users\Application Data
Access denied
For the second one, it does not specify exactly what it was trying to do when it encountered this denial.
Anyway, this worked like a charm on my XP system. I tried executing it as administrator (I still don’t understand why Vista requires this for some programs when my user is an administrator anyway), with the same results.
I can just do a plain copy using Explorer, no problem.
Does Vista have restrictions about using command-line xcopy that were not imposed by previous versions?
(I like to use my bat file method because I can do incremental backups by using the archive bit, and the backup directory is a mirror of the source directory, rather than some esoteric compressed format, and I don’t have to mess with an application to do it.)
Try using robocopy. Last time I had trouble with xcopy under Vista, robocopy seemed to work ok. It’ worth a shot.
Update: Specifically, you might want to try robocopy /b to enable “backup mode”, whatever that means. A Google search suggests that xcopy might have trouble with Vista’s new UAC, even if you are admin.
When you ran the command prompt, did you right-click on it and pick Run as Administrator? I’m sure I’ve used XCOPY in Vista. However, I haven’t tried to mess with the Application Data directory, maybe that’s the problem?
There’s a good XCOPY alternative called XXCOPY that might be worth a try. It supports the XCOPY command line switches, plus many more, including ones that might be useful in your backups.
Not an answer to your original question, but if you’re looking to create incremental backups of your data, try SyncToy. It’s a simple, free power toy from Microsoft:
I am trying Robocopy right now But it hung. It is sitting there at the bottom of the CPU util list with no signs of life. It created a directory and a file or two then just fell off the face of th earth.
xcopy is not deprecated; I’m assuming that by “deprecated,” **Quartz **means it is still there for compatibilty but no longer does anything, which is what I’ve seen that used to mean in the Java world. But it definitely performs to spec. It’s just that the way it works under Vista HP is different than how it worked under XP.
SyncToy looks like it fits the bill, too. I will take a closer look at that. BTW SyncToy could also solve some other problems I have as well.
You are running into a NTFS permissions problem - your account does not have the rights to access the source directory.
Your local administration rights are not active all the time - Vista restricts accounts to non-administrator functions until you need elevated privileges. Things running from the command line may not trigger the rights elevation you need. The gui tools tend to elevate privileges correctly.
You could browse to C:\Users, right click All Users, select the Security tab, add your user with Read rights and select the apply to files and sub-folders. This should give the ability to read the files from the non-privilege state.
No, that’s not what’s going on here. As detailed in this article, Vista has moved the locations of most of the user profile’s folders, and set up “junctions” that redirect legacy programs. By design, the permissions on these junctions are set to deny attempts to list their contents. The backup script should be altered to avoid attempting to access files through these junctions.
“Deprecated” in Windows world means “Stop building anything long-lived which uses this feature. It is still fully functional in the current version, but we intend to remove it in some as-yet-undetermined future version. When we do that, your stuff will break. And we may not tell the world about this feature’s impending removal until very close to the release date for that future version. So smart people will start migrating away from this feature to the new stuff now, to avoid problems later.”
I don’t think that’s what I’m trying to do. I am just executing one command. E: is the backup drive and C: is the usual:
E:
cd E:\HOME-PC\Users\CookingWithGas
c:
cd C:\Users\CookingWithGas
xcopy . E: /e/c/f/h/k/r/y
I can’t figure out why there would be any permission issues doing this. The first time I tried this I was one level higher, but it still fails even here where I should have all necessary permissions.
Well, while I like the fact that MS have moved back to a less cute folder naming scheme for settings, and that they have attempted to provide appropriate compatibility, using junction points in this way just leaves me :eek:
And MS wonder why corporate OS deployment teams prefer to continue deploying XP rather than Vista - the devil you know and understand, and all that.
