The line below previously worked with Win-10Home; dirtree remained intact.
robocopy D: A:Bak_Up /E /ZB /dcopy:dat /LOG:A:Bak_Up.log /TEE
By comparison, using Win-11Home from the below .bat, will not create the dir tree; Robocopy dumps the individual files in the dest dir.
@echo off
Setlocal EnableDelayedExpansion
cd /d A:45011
robocopy %CD% E:45011TEMP_08_Day_From_A /S /ZB /MOVE /LOG:E:45011TEMP_08_Day_From_A_08_Days.log /TEE
Robocopy /? — clearly states, /MOVE :: MOVE files AND dirs (delete from source after copying).
It does not specify to use /MOVE with any other option to recreate the original dir tree. However, the following within a .bat, does recreate and/or ‘move’ the dir tree. The notable difference is the destination.
@echo off
Setlocal EnableDelayedExpansion
cd /d A:45011
robocopy %CD% E:45011 /S /E /ZB /MOVE /LOG:E:45011TEMP_08_Day_From_A_08_Days.log /TEE
Question 1) What is the above issue causing the confusion between what the help file states should be the resulting output, compared to the actual Robocopy output?
Below is more evidence that Robocopy, or cmd.exe, is just plain misbehaving. From an elevated prompt:
A:45011>For /f %i in ('dir /b ') do robocopy %i E:45011TEMP_08_Day_From_A /XD 2024*2? /S /ZB /MOVE /LOG:E:45011TEMP_08_Day_From_A_08_Days.log /TEE
Initally, using the above command-line, the dir tree was in-fact being recreated in the destpath, then deleted from the srcpath. There was a brief regional power-outage for approximately five minutes; then Rcopy resumed, unknown at the resumed time, the bare files were now being dumped into the destpath; no more dirtree.
Subsequently there was another brief pwr-loss, this is when we discovered the dirtree was no longer being recreated. We then manually cancelled with ^C; then restarted using the same elevated prompt and line shown above. The bare files continue to be dumped in the destpath without any sub-directories.
Even though there was a pwr-loss, the machine remained ‘on’ battery. The usb-connected drives needed to wait for power restoration.
Question 2) What might be causing the above behavior?
Last item of Rcopy misbehaving, see image showing ‘dir /b’ in the ‘left’ elevated prompt, compared to the active Rcopy output, seen in the ‘right’. Rcopy appears to be writing files that no longer exist in that dir; or anywhere on that hdd.
To be clear, the parent dir is A:45011 containing a list of sub-dir’s named yyyymmdd.
Question 3) What might be causing this problem shown in the image?
Below is what currently works:
@echo off
Setlocal EnableDelayedExpansion
cd /d A:45011
robocopy %CD% C:45011 /S /E /ZB /DCOPY:DAT /MT:16 /MOVE /XD 2024*3? "Download Record" "Manual Capture" "Manual Record" VMS_ALARM_Sounds _Reports /LOG:C:45011_Days.log /TEE
Our Goal is to /COPY or /MOVE the original dirtree to any custom-named dir, not an exact match of the original parent-dir name.
