ReadOnly, /ignorepattern, versus RoboCopy
tomg
1) A Bug/Feature Request,
2) a vote for a previous Feature Request,
3) and a comment on future directions.
1) Needed; A way to overwrite Read-Only files.
This is needed when doing back-ups. Sometimes
a RO file has actually been updated
(configuration files for instance). As
currently implemented, the only options are
to ignore it using /skipdenied, manually clear
the RO attribute on the existing back-up, or
manually delete the file from the existing
back-up before running HoboCopy.
2) Open Issue #26 /ignorepattern
I agree /ignorepattern or similar is needed.
For instance Restore Points (System Volume
Information) and temporary directories are
not always needed. A way to skip them
would be quite useful.
3) HoboCopy as a shell for RoboCopy
One of the nice things about HoboCopy is it
runs in the background, not having a great
impact on user response time. Robocopy
however, saturates the disk I/O causing
other disk accesses to stall. Not nice
if data logging or video editing is going on.
Also, do you really want HoboCopy subject to
the corporate whims of the Robocopy folks? ;-)
Overall, I feel the strong points of HoboCopy are:
uses VSS, background operation, ease of use,
complementary to RoboCopy functionality. In fact
I often use them together, for instance it is
possible to defrag directories when restoring from
a back-up.
Tomg
Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com
Craig Andera
> 1) Needed; A way to overwrite Read-Only files.
> This is needed when doing back-ups. Sometimes
> a RO file has actually been updated
> (configuration files for instance). As
> currently implemented, the only options are
> to ignore it using /skipdenied, manually clear
> the RO attribute on the existing back-up, or
> manually delete the file from the existing
> back-up before running HoboCopy.
Agreed that this would be useful. I've entered feature request #40
(https://github.com/candera/hobocopy/issues/40).
> 2) Open Issue #26 /ignorepattern
> I agree /ignorepattern or similar is needed.
> For instance Restore Points (System Volume
> Information) and temporary directories are
> not always needed. A way to skip them
> would be quite useful.
Yeah, my objection to /ignorepattern was always around the use of
regular expressions, not the idea of being able to exclude a file or
set of files. How would you feel if we were able to support exclusion
of files, but you could only specify particular files? I.e. literal
matches only, no globbing or regexp support?
> 3) HoboCopy as a shell for RoboCopy
> One of the nice things about HoboCopy is it
> runs in the background, not having a great
> impact on user response time. Robocopy
> however, saturates the disk I/O causing
> other disk accesses to stall. Not nice
> if data logging or video editing is going on.
> Also, do you really want HoboCopy subject to
> the corporate whims of the Robocopy folks? ;-)
>
> Overall, I feel the strong points of HoboCopy are:
> uses VSS, background operation, ease of use,
> complementary to RoboCopy functionality. In fact
> I often use them together, for instance it is
> possible to defrag directories when restoring from
> a back-up.
Interesting timing on this: I'm just now trying to set up some backups
with shadowspawn+robocopy and I find I'm missing the way hobocopy does
incremental copies. However, I still think that it's much more
flexible to have two tools that do one thing than one tool that does
two things. And robocopy is far from the only tool that shadowspawn
supports. For example, xcopy already has options that cover both
excluding files and overwriting read-only files. Would shadowspawn
plus xcopy work for you?
Assuming the answer is "no", and assuming I don't want to just enhance
hobocopy as-is, one option would be for me to extract the copying bit
of hobocopy into a separate program, which could then be called by
shadowspawn. We could even provide a shell script or an executable
that would wrap the two together for convenience (giving you something
like what hobocopy is now). But the truth is, I'm not sure I'm
interested in maintaining a copy program. Copying has lots of subtle
issues that are hard to get right, and there just has to be something
better than whatever I could come up with. Plus, I moved away from
writing code for Windows over a year ago (and C++ something like ten
years ago), so I'm not particularly motivated to spend more time in
that space.
None of which is to say that I'm sure about what I want to do yet. I
need to think it over some more. And I don't have time to work on it
at the moment in any event.
My apologies for not having a better answer for you: I really do
appreciate it when people take the time to give their feedback, so I
wish I was able to say, "Yep, I have a patch for that."
I'll do some serious thinking about this over the next few weeks and
try to see if I can figure out what makes the most sense.