The last two XCOPY commands work fine. The first one, however, yields the following error:
Access denied
Unable to create directory - Z:\Backups\davalynn backup\My Documents
File not found - .
0 File(s) copied
All the directories referenced in the batch file exist on the Z:\ drive - I created them myself. There must be a syntax problem somewhere, and I’ve been looking at it for so long I can’t see it.
Any suggestions (other than to use something other than XCOPY) would be greatly appreciated.
Disclaimer: I’m only doing this because you specifically forbid it.
Have you considered using deltacopy?
P.S. The access denied message implies that the problem is permissions on a directory or files in the directory, as opposed to any issue with the directories existing. Is the batch file being run with administrator permissions?
So far I’ve been calling the batch file from the command prompt, which is open with admin permissions. I’ve been testing by just running the one line from the command prompt.
So if you just copy that line from the batch file to your command prompt, you get the same permissions errors?
I’m betting your local admin account must not have permissions to some aspect of that Z: mount. I’m not much of a windows security guru so I don’t have good advice on how to diagnose exactly what, other than to just “cd Z:Backups\davalynn backup\My Documents” and see if there’s any file it won’t let you fiddle with.
“My Documents” is probably a special case here because it’s a junction point, not a directory. I’m not sure how xcopy is even supposed to handle them, but it’s also possible that the destination can’t handle it as well, if it’s a network share or FAT32 drive or something.
A junction point basically makes the target directory accessible through a different point in the filesystem. You can navigate to it and do stuff in it just like a regular directory, but you’re actually affecting the directory it points at. Xcopy doesn’t seem to handle them very well, from what little information I’ve been able to find.
As of Vista and Win7, \Users\whoever\My Documents is just a junction point that actually points to \Users\whoever\Documents, so you could back that up instead.
Edit: Go to your user directory and do a “dir /ah” and it should show you all of the junction points there and what they’re pointing at.
I was very confused about this issue when I went from Vista to Windows 7. Suddenly the name of this folder had changed back from “Documents” to “My Documents”… with a junction also called “My Documents” pointing to the real “My Documents” folder in the same directory!
Now I’ve looked a little closer and found that Windows 7 cheats: the actual folder is called “Documents” as in Vista, but it seems to have some special shell attribute so that when looking at the directory with Explorer or Speed Commander instead of the command prompt, the name of the “Documents” folder appears as “My Documents” – same as the junction.
And now I also found the responsible Speed Commander setting: “Show localized names for files & folders”. Sounds like a misnomer to me – “My Documents” is the shell folder version of “Documents”, not the localized name. But whatever… at least now I’m seeing the actual folder names again. There does not appear to be an equivalent setting in Windows Explorer, though.
They call it ‘localized names’ since that’s where they now do the translation into different languages. The directory name in the filesystem remains “Documents” no matter which language edition of Windows it is, but the displayed name changes based on your language setting, and “My Documents” is the English localized version.
Previous versions instead changed the actual directory names in the filesystem, but they can’t do that anymore now that you can potentially have different languages for different users on the same system through the multilanguage packs. It’s still a mess, but it at least starts to make some sense.
The Documents folder is represented by a Shell API function, not an environment variable. But developers are no longer forced to use that either, because they can now rely on the actual folder being called “Documents” across all installations. So… quite the opposite, really.
