Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

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

May
14
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:
/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.
Or refer users to SYNC?
 
/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.
 
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).
 
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.
 
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.
 
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?
 
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.
 

Similar threads

Replies
7
Views
2K
Back
Top