View Full Version : "Copy Newer" and "Copy Different" ???
08-14-2004, 06:56 PM
I just purchased this program and I am finding it very useful. However, I do not understand the meaning of the "Copy Newer" and "Copy Different" options. Can anyone clarify the meaning of these options by perhaps giving an example of both choices showing how they differ?
Thanks for the help.
08-14-2004, 10:31 PM
Hi, Martin. Before I go into detail here, did you find the explanation in the manual confusing, or was it not something you saw when you were going through it?
Let me try to explain what the deal is. Basically, when copying from the source to the destination, SuperDuper! has to decide what to do in the case where a file being copied from the source is already on the destination in the same location, with the same name.
When "Copy newer" is selected, the file on the destination is replaced with the one from the source if the file on the source has a later (newer) modification date.
When "Copy different" is selected, the file on the destination is replaced with the one from the source if the file is different in date, size, HFS+ meta data, etc. So, the file on the destination is basically replaced if it's not exactly the same as the source file.
Make more (any?) sense?
08-15-2004, 01:59 AM
Thanks for the prompt help Dave. I did read through the manual thoroughly several times. Your explanation cleared it up. It really just came down to the meaning of the words.
08-15-2004, 09:01 AM
OK. I've got to figure out what I need to change in the manual, since I get this question reasonably often... I'll take another pass at it there for the next release!
Sorry that you found it confusing!
08-15-2004, 11:15 AM
OK, I've reworked page 10 of the manual a bit to -- hopefully -- improve the description. What do you all think? Is this clearer?
Copy newer and Copy different, the other two During Copy options, control what SuperDuper! does when it copies a file from a folder on the source volume to the destination, and finds thereís already a file in that location with the same name.
When Copy newer is selected, the file on the destination is replaced with the one from the source if the file on the source has a newer (more recent) modification date.
Copy different replaces the file on the destination if the source file is different (not necessarily newer) in date, size, HFS+ meta data, attributes, etc. So, the file on the destination is replaced if itís not exactly the same as the source file.
In both cases, files on the destination that are not on the source are left as-is.
This thread reminds me of something I've been meaning to ask and hadn't gotten around to testing it...
When "Copy newer" is selected, the file on the destination is replaced with the one from the source if the file on the source has a later (newer) modification date.Does "Copy newer" cause SD! to ignore a newer version of a file that's, say, been recently downloading but happens to have older modification date than the older version of that file on the backup target? Or will SD! detect that the file is newer on the source by its "change time", similar to using the -newerct option of the find command?
The latter seems the more intuitive and desirable behavior, without depending on possibly misleading modification dates. And the example above is real because Safari sets the modification date of a downloaded file to whatever it is for that file on the destination server, if possible. Other utilities, like wget, can also behave that way.
08-16-2004, 07:36 AM
There are three dates you can use to make this kind of determination:
struct timespec st_atimespec; /* time of last access */
struct timespec st_mtimespec; /* time of last data modification */
struct timespec st_ctimespec; /* time of last file status change */
We use st_mtimespec. st_ctimespec, which I believe you're referring to here (at least, the documentation for find specifically says it's looking at the inode change time, not the file modification date), takes into account some operations that aren't explicitly "newer" -- things like chmod, chown, etc -- which are covered by Copy Different... st_ctimespec seems to me to not say the "file is newer", but rather the "inode is newer", which is much different, and a lot harder to explain to the non-technical.
Give it a try and see if you think the behavior is undesirable in practice...
There are situations when files appear to be "newer" than their modification times from a user's perspective. The download example was one case. Another might be where a directory hierarchy is reverted to a chronologically older copy which is then considered the "newer" version.
In situations like that it's risky relying on file modification times for backups, which is how I understand Copy Newer to work. From your description it sounds like Copy Different includes "inode is newer" files (detected with a st_ctimespec or equivalent change), which is the behavior I'm mostly interested in.
Now, it's debatable which method makes "more sense" to users. Seems to me Copy Different is generally more natural because it's relative to the user's perception of when files have actually changed, e.g. the content differs, irregardless of modification times.
Just because files have changed doesn't necessarily make them newer, which might cause Copy Newer to produce inaccurate, unexpected results. Knowing whether files have changed in "my" time or "their" time can be confusing.
I think your reworked explanation posted here (which I didn't notice 'til after my post) makes the Newer vs. Different distinction quite clear. Maybe some usage example for both would help in understanding which might be useful in which situations and for avoiding unexpected results like I've just tried to describe.
08-16-2004, 06:38 PM
The thing is, it just doesn't seem like the situations you describe are going to be very common at all, don't you think?
The vast majority of the time, people use Smart Update (as opposed to Copy Newer), and Smart Update does use Copy Different as its base algorithm.
The reworked description makes the concept of modification time clear, but I think going into more detail brings up some details that require a pretty thorough understanding of Unix to "get" -- something that most of our users don't have. Hopefully, those who do worry about this rare situation will take the time to ask, experiment, or read this forum!
You're probably right about Smart Update being used most often. And it seems the most foolproof and intuitive copy option, especially for someone familiar with clone backups. Heck, it's a big reason why I bought SD! :)
Yes, your description of modification time is good. I was questioning whether users would be aware of situations when modtime might unexpectedly change on certain files and adversely affect Copy Newer backups. Maybe that's likely to happen more often than usual with files on my systems because of how I create/modify/update them.
Thanks for the feedback!
08-16-2004, 09:48 PM
I think that's probably true -- users who do things like this tend to be the kind of users who are aware of exactly these kinds of issues...
Thanks for the discussion.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.