site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 30, 2006, at 12:04 PM, Dan Shoop wrote: It should be noted that there are two viable, separate, operations: A - copy a file (make a new file whose contents are the same as the original) B - duplicate a file (make a file that is in every way practical identical to the original) Both of these have their place, and the Unix™ philosophy supports both. No, it is not. It is a result of cp(1) performing operation A. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Historically, Mac OS and UNIX had a very different perspectives on file copying. UNIX considers the copy to be a new file that just happens to have the same content as the original. It should be noted that the parlance used by the Macintosh is that it duplicates a file. This implies that that the file is a duplicate of the original, rather than a 'new copy'. It is worth noting that by precisely cloning a file, you may inherit arbitrary attributes of the original of which you are unaware and which it may not be in your interest to inherit. It is also worth noting that there are attributes of the original that the system may not want, or permit, you to copy. Thus for an application that cares, operation B may be built out of a combination of operation A and a selective transferral of attributes, or operation B followed by a selective elimination, depending on circumstances. Mac OS tries to make the new file as close as possible to the original. This affects other things beyond the permissions. For example, if you copy a file on traditional Mac OS (or using technologies that conform to traditional Mac OS semantics, like the Finder), the new file has the same creation and modification date as the original. If you do this using "cp", the new file's creation and modification dates are set to the time that you did the copy. Which is caused by confusing the Mac Creation Date of a file with the unix ctime You could reasonably argue that the -p option to cp(1) implies operation B, and that a failure to preserve the creation time attribute is a bug in cp(1), but the conclusions you draw from your assertion above are in error. Normally when two different systems have properties common to each and other properties unique to each the system w/o the unique properties defers to the other system or ignores the property of the other rather than destroying or invalidating the non-orthogonal property. Why the choice was made to trample on the unique property of the other system in this case seems misguided and unnecessary. I trust that the above elaboration will finally cause you to leave the corpse of this departed equine well alone. There are bugs that are worth filing, if you haven't already. But there are also points that you need to absorb if this discourse is to be fruitful. This email sent to site_archiver@lists.apple.com