"copy /z /w" command not deleting read-only files in destination

May 30, 2008
9
0
Given two directories "C:\T" (the source/working directory) and "G:\T" (the destination/backup directory). Executing:

copy /z /w /u /y c:\t g:\t

What happens to read-only files in the destination depends upon if the corresponding file exists in the source director.
  1. If the corresponding file exists in the source directory, the destination file is updated and the read-only attribute is removed.
  2. If the corresponding file does not exist in the source directory, the copy command indicates that the destination file is deleted without actually deleting it nor changing its attributes.
I am using TCC 24.01.41 x64 Windows 10 [Version 10.0.17134.590]
 
Last edited:
May 30, 2008
9
0
/Z isn't supposed to delete files, it's intended to overwrite existing (readonly) files.

I'm going to have to think about whether to allow /Z to delete, or to add another option specifically for that purpose.
Another flag would be fine. I'd just like to point out that the current implementation does output a message that it is deleting the existing read-only files.
 
May 30, 2008
9
0
I found to handle hidden and system files with robocopy requires two passes, the first for normal files (no /IA: option) and the second for the hidden/system files (with a /IA:SH option).
 
Aug 23, 2010
388
5
I'd be surprised if that's actually true.
Try specifying * as attributes list or not specify the list at all.
As last resort, specify all attributes.
 
May 26, 2008
505
3
I found to handle hidden and system files with robocopy requires two passes, the first for normal files (no /IA: option) and the second for the hidden/system files (with a /IA:SH option).
Nah, just don't use that /IA parameter at all. If you want to do make DST look exactly like SRC you can use something as simple as:

robocopy.exe src dst /mir

be careful... /mir will delete files in DST that no longer exist in SRC. If you don't want that, use /e instead.
 
May 30, 2008
9
0
Interesting, I've been using ROBOCOPY since Window XP when I first wrote a batch file to handle all of the common options. The batch file had two work arounds because of issues with ROBOCOPY. 1) The Windows 7 version had a bug that caused a destination directory to be marked as hidden/system if the source was a drive. 2) Check for hidden and/or system files because they were normally ignored. I can finally remove both of these work arounds. I wonder when they corrected this?
 
May 26, 2008
505
3
Item 1 isn't technically a bug. The root directory really does have the HS attributes set. Robocopy dutifully replicates that in the target. I do agree that this is probably always not desired, but you can easily undo it by running attrib after the robocopy command.

I don't know about item 2. As far as I know robocopy has never skipped such files by default, but it's been a long time since I've used the robocopy from XP/2003 days.