New
#11
I should have mentioned that the time / date stamps are critically important.
That is why I am using Robocopy.
I should have mentioned that the time / date stamps are critically important.
That is why I am using Robocopy.
You are making it too hard for yourself énd overthinking it I think (unless I misunderstand your requirement)
On PC1 copy with /E to backup drive Z.
On PC2 copy with /E to backup drive Z.
Backup drive Z will then have latest version from both but also contain files from PC1 or PC2 that don't exist on the other.
If you want to replicate deletions using/MIR
you can but it could get confusing if you aren't sure which source is primary.
Download the free GUI for robocopy that writes the CMD for you so you know it's right
What you describe is what I use MirrorFolder for? It's not free but it sure does a great job of keeping disparate files and folders in sync across multiple drives and across multiple PCs. I've been using it for many years.
A single computer license for MirrorFolder costs US $39.00
Thank you again for for your sage comments and suggestions and patience lx07.
Granted I do have a strong tendency to "overthink" some times. That springs from my desire for high levels of precision and wanting to "look before one leaps" and a lack of skills for intuitively being able to fill in blanks in very unfamiliar complex discourse -- such as Microsoft documentation.
I see your point withe the /E switch. I think I dismissed it from the start because there is no explicit mention of how it handles time / date stamps. Maybe I missed that in all the murk? Again these are critical pieces of information from the source file. I now vaguely recall your earlier comments that prompting me to clean up the redundancy in my base command.
The following provided some insights, but still strikes me as not fully definitive with respect to the time/ date stamps.
From:
robocopy | Microsoft Docs
1. /ts Includes source file time stamps in the output.
This led me / leads me to think that time/ date data is not included by default?
In my early loops that is why I tuned to explicitly specifying preservation of them by specifyingCode::/MIR /COPY:DAT”
So if I understand you right now Robocopy natively preserves time / date data unless told to not do so?
2./e Copies subdirectories. Note that this option includes empty directories. For additional information, see Remarks.
- The /mir option is equivalent to the /e plus /purge options with one small difference in behavior:
- With the /e plus /purge options, if the destination directory exists, the destination directory security settings are not overwritten.
- With the /mir option, if the destination directory exists, the destination directory security settings are overwritten.
# So if I have all of this right finally first establishing an empty destination folder then using the /e switch as below will properly name the destination directory with preservation of the time / date and other data
Recasting my base command.
ROBOCOPY
C:\Users\mikei\Documents
J:\HP.Files /E /XD
"C:\Users\mikei\Documents\FeedbackHub"
"C:\Users\mikei\Documents\Cyberlink"
/v /tee /ts /log:"I:\log.HP.temp.txt"
.............................
Last in passing.
From Robocopy /?
#I am unable to decode this but it seems to speak to the issue of naming the destination with “Directory.”?
: Remarks :
::
Using /PURGE or /MIR on the root directory of the volume formerly caused
robocopy to apply the requested operation on files inside the System
Volume Information directory as well.
This is no longer the case; if either is specified, robocopy will skip any files or directories with that name in the top-level source and destination directories of the copy session.
I thought I had this figured out, but I was wrong.
Robocopy did not like the punctuation in the directory name. Part was the period. Part was an error on my part, picking up a trailing space when I copied the directory name from the command.
With those cleared the command nicely put all the HP Files in the the HPFiles destination directory. / E and /MIR both did the job.
I unmounted the destination folder and went elsewhere.
Then I came back and clicked on the HPFiles folder.
It immediately change to "Documents."
Same as before. Shows in the file tree and Properties, but not in the delete tool.
Any new suggestions?
I am mirroring to an external drive, not the HP.
Now after all this I think that "Documents" is "hard coded."
Suspect what is needed is a way to intervene in that structure?
Or find a way to recursively march through the file tree one step down from "Documents:?
Or figure out a way to mirror the files without Robocopy?
Take the project to Linux as one participant here suggested?
Now open to any and all fixes or alternates, with the easier one taking priority.
Last edited by mikeincousa; 27 Sep 2018 at 08:15.
This is the bit that confuses me.
Are you sure you want to mirror? That would mean that if you deleted something from source it would be deleted from the destination. As I read your earlier post you wanted the backup not to have stuff deleted in case you deleted stuff from source by mistake.
In any case there is no advantage or disadvantage using robocopy compared to rsync really that I can think of. Either will take the latest version of a file (or directory) and replace the one that is there. I run Windows, Linux and MacOS and use robocopy on Windows because it works fine.
What I'd do (and what I do do) though is not copy "Documents" as the old hard links confuse it. Easier to make a batch file that says explicitly what you want to copy from point A to point B.