Using robocopy, copying files from “A” to “B” as a manual backup process.
I have a handful of files that kick back that the file is in use. I can go to the file, copy the file in the same director (windows renames it with ‘copy’), and then delete the OG file and it copies w/o issue. But…if I do the same process, delete the OG and rename the ‘copy’ file as the same as the OG, it fails.
This suggests perhaps an alternate streams issue, but I’ve cleared them and disabled alternate streams on the shares to block them.
I have done this dozens of times over the years and had stopped as I started using replica functions and cloud-replicas; but then I was using this to restore the “A” server as I wanted to change from mirrored vdevs to Z2 to gain some space, and ran into this issue. I was able to recover the files via different methods; cloud-recovery deposited the files w/o issue; alternative I could copy the file (or the directory) and delete hte offending item, replicate again and it would be fine; but as I rename the copied item back to the original name(s), it would choke again.
Any thoughts or assistances would be great, thank you!
What is the Robocopy command you are using? What kind of files are causing trouble? Are these data files or are they something like system files for Windows?
It would help if you describe your setup and the machines in a bit more detail. I can’t tell where the data is coming and going to or if there is a permissions / user errors
I did find that rather than copy the item or director, I can just rename a directory and it’ll copy the files w/o error. It’s getting hung up on a variety of files.
robocopy \server-a\share server-b\share /copy:dat /mir /r:999 /w:999
Also does it if I reverse direction if I had sync’d via ‘replica’ function (assumed zfs send/receive), and the files I pulled down that were cloud restored; while they restored just fine, seemed to carry the oddity with them.
Generally I’d suspect there’s a alternate streams involved, but I don’t recall that being a directory item.
It does not affect all files under a given directory.
Adding more tot the story, with what looks to be a client issue more than anything else.
I have 3 servers. I renamed top-level directories that had files that couldn’t copy, only to have them complete. IE, A to B, without rename, would have some files fail due to file in use error. Rename an upstream directory, A to B would succeed without issue.
Renamed the directories back on B to what they were before, copied from B to C no problem.
Copied from B to A, it would hang up on the same files.
Reinitialized “A” server, including quick wipe of the disks (SSD and NVMe, FWIW), and started copying data again, and…failure on the same exact files, no matter if I used B or C as the source. Ruling out what I could, I tried from another PC on my network (a VM) and…it copied without issue.
So…guess I can either dig into WTF my PC cares about a handful of files vs the 100’s of 1000’s…but at least I have something to work from.
Anyone have ideas?
