October 2006 - Darwin-kernel

Re: cp creates directory with different permissions -- then reverts them
by Michael Smith 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… 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(a)lists.apple.com

1 0

Re: cp creates directory with different permissions -- then reverts them
by Dan Shoop 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com It's the UNIX way (-: I'd love to discuss this off-list with Apple Engineering. -- -dhan ------------------------------------------------------------------------ Dan Shoop AIM: iWiring Systems & Networks Architect http://www.ustsvs.com/ shoop(a)iwiring.net http://www.iwiring.net/ 1-714-363-1174 "The wise man doesn't give the right answers, he poses the right questions." -- Claude Levi-Strauss ------------------------------------------------------------------------ iWiring provides systems and networks support for Mac OS X, unix, and Open Source application technologies at affordable rates. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 9:38 AM +0100 10/30/06, Quinn wrote: At 23:06 -0800 29/10/06, Jeffrey Ellis wrote: Can someone tell me why cp is doing this? 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'. 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, which (contrary to much misinformation) is not the creation time of the file at all but the change time of the file, something best associated with the Mac concept of Modification Date. Unix doesn't have a concept of creation time. Why the Apple BSD engineers have then also chosen to clobber Creation Date as well properly updating the Modification time of a file just b/c they think the Mac's concept of Creation Date is a gross error in a 20+ year design seems misguided since normally when two systems have unrelated properties between them the information is normally either preserved or Indeed this preserving behavior for such foreign systems -- and the preservation of Creation Date -- was long ago codified as part of AppleDoubles. Yet here the behavior in the "unix" side of Mac OS clearly does not follow what should be the documented behavior and the Apple Double "Creation Date" property is once again clobbered by mtime, creating a bad AppleDouble. There are many arguments as which of this approaches is 'correct', but they are mostly pointless IMHO. Both approaches have their pros and cons. Regardless of which method you consider to be correct, since the two properties are not related the unrelated property of the other method should not be invalidated, munged or clobbered -- yet it is. This flies in the axiom of "cause no harm" when dealing with foreign properties. 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. Fortunately, Mac OS X bypasses these arguments by providing you with tools to do both. "cp" gives you the traditional UNIX semantics. At the expense of clobbering a perfectly valid and different property of the Mac semantics. "ditto" gives you the traditional Mac OS semantics. Actually, ditto does not preserve exactly the same set of metadata as the Finder. Ditto does not preserve ACLs where both copying (option-drag to a new location) and the "Duplicate" feature of the Finder will. In fact there is no command line tool that duplicates the functionality of the Finder in this regard. This email sent to site_archiver(a)lists.apple.com

1 0

Re: cp creates directory with different permissions -- then reverts them
by Michael Cashwell 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 30, 2006, at 1:36 PM, Michael Smith wrote: On Oct 30, 2006, at 9:01 AM, Jeffrey Ellis wrote: -Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… ... It has only System as owner, and no access for anyone else. drwx------ chmod 700. Of course, this changes when the copy is finished, but the user will be alerted as to the initial settings of the folder, as it appears with a great big "No Access" icon. Can you suggest what I might be doing to cause this? The initial mode for the folder will be modified by the process umask. It sounds like yours is 0700 or similar. The real question might be "how do you tell the Finder to resync its view of the folder that's been copied", and there I fear I can't help you. Other folks here surely can, though. One approach I've seen for this is to do the scribbling (writing, copying, changing of permissions, etc.) somewhere hidden on the same file system and then when that's finished move the item to the Finder- visible location. This email sent to site_archiver(a)lists.apple.com

1 0

Re: cp creates directory with different permissions -- then reverts them
by Michael Smith 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 30, 2006, at 9:01 AM, Jeffrey Ellis wrote: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… So here's the problem I'm having. In the app I'm doing, I use a call to cp to make the copy. But unlike when using cp in terminal, somehow the directory it's creating is a bit worse than normal. It has only System as owner, and no access for anyone else. drwx------ chmod 700. Of course, this changes when the copy is finished, but the user will be alerted as to the initial settings of the folder, as it appears with a great big "No Access" icon. Can you suggest what I might be doing to cause this? The initial mode for the folder will be modified by the process umask. It sounds like yours is 0700 or similar. The real question might be "how do you tell the Finder to resync its view of the folder that's been copied", and there I fear I can't help you. Other folks here surely can, though. This email sent to site_archiver(a)lists.apple.com

1 0

Re: cp creates directory with different permissions -- then reverts them
by Jeffrey Ellis 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: Acb8RP2kPG2v2Gg4EduJHgANk0QgEg== Thread-topic: cp creates directory with different permissions -- then reverts them User-agent: Microsoft-Entourage/11.2.5.060620 Hi, Mike-- Thanks very much ;) So here's the problem I'm having. In the app I'm doing, I use a call to cp to make the copy. But unlike when using cp in terminal, somehow the directory it's creating is a bit worse than normal. It has only System as owner, and no access for anyone else. drwx------ chmod 700. Of course, this changes when the copy is finished, but the user will be alerted as to the initial settings of the folder, as it appears with a great big "No Access" icon. Can you suggest what I might be doing to cause this? All My Best, Jeffrey on 10/30/06 5:20 AM, Michael Smith at drivers(a)mu.org wrote: > > On Oct 29, 2006, at 11:06 PM, Jeffrey Ellis wrote: > >> I have just noticed that when doing a copy of a directory, the copy >> of the >> directory has different owner/group and permissions than the >> original, and >> when done, has reverted back to the original permissions. >> >> This was my test directory. Here is my output during the initial >> stage, just >> after copying has begun: >> >> drwxr-xr-x 4 root admin 136 Oct 29 22:56 Mixdown Project >> >> And when the copy was complete: >> >> drwxrwxrwx 8 jeffrey jeffrey 272 May 6 2005 Mixdown Project >> >> I was sudo'd to do the cp. >> >> Can someone tell me why cp is doing this? > > There are several reasons. > > Firstly, the mkdir(2) system call does not provide a way for the > owner/group to be set on the destination (since that would only be > useful to root, anyway). > > Secondly, the directory has to be left as it was created until the > copy is complete because the final mode for the directory may > preclude creating files within it. > > Those two cover most cases. > > = Mike > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: cp creates directory with different permissions -- then reverts them
by Michael Smith 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 29, 2006, at 11:06 PM, Jeffrey Ellis wrote: drwxr-xr-x 4 root admin 136 Oct 29 22:56 Mixdown Project And when the copy was complete: drwxrwxrwx 8 jeffrey jeffrey 272 May 6 2005 Mixdown Project I was sudo'd to do the cp. There are several reasons. Those two cover most cases. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have just noticed that when doing a copy of a directory, the copy of the directory has different owner/group and permissions than the original, and when done, has reverted back to the original permissions. This was my test directory. Here is my output during the initial stage, just after copying has begun: Can someone tell me why cp is doing this? Firstly, the mkdir(2) system call does not provide a way for the owner/group to be set on the destination (since that would only be useful to root, anyway). Secondly, the directory has to be left as it was created until the copy is complete because the final mode for the directory may preclude creating files within it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: cp creates directory with different permissions -- then reverts them
by Quinn 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com It's the UNIX way (-: S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 23:06 -0800 29/10/06, Jeffrey Ellis wrote: Can someone tell me why cp is doing this? 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. 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. There are many arguments as which of this approaches is 'correct', but they are mostly pointless IMHO. Both approaches have their pros and cons. Fortunately, Mac OS X bypasses these arguments by providing you with tools to do both. "cp" gives you the traditional UNIX semantics. "ditto" gives you the traditional Mac OS semantics. This email sent to site_archiver(a)lists.apple.com

1 0

cp creates directory with different permissions -- then reverts them
by Jeffrey Ellis 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: Acb78e2vLETu0mflEduJHgANk0QgEg== Thread-topic: cp creates directory with different permissions -- then reverts them User-agent: Microsoft-Entourage/11.2.5.060620 Hi-- I have just noticed that when doing a copy of a directory, the copy of the directory has different owner/group and permissions than the original, and when done, has reverted back to the original permissions. This was my test directory. Here is my output during the initial stage, just after copying has begun: drwxr-xr-x 4 root admin 136 Oct 29 22:56 Mixdown Project And when the copy was complete: drwxrwxrwx 8 jeffrey jeffrey 272 May 6 2005 Mixdown Project I was sudo'd to do the cp. Can someone tell me why cp is doing this? Thanks :) All My Best, Jeffrey _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Upgrading a ROM based KEXT
by Satyam Lad 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=s23Dxoi5Ex/R/7Y6ofrjwjcOUaFQcX5chGBvQIddQ1+dA4MQHDROP0ddfWkn1kPyR2H85XrBWH5fGi7OSGGO00ClnnnviVr2N6KrBmU2GL4F6Ui0ZiHAJmlKSlfFGt+ktwSGjSz7S8gimiue+iRl+VyvVv3MxV7/JRCaf3oy4Xs= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Fwd: Upgrading a ROM based KEXT
by Satyam Lad 30 Oct '06

30 Oct '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Vfnz6q8maUowGUXsAoGgsTCch/HY+hJxuzsTpsbbUNxWfb53krW1KqwpqLx3pnj1DywiuqhEsIPNXH0oVy69EGcJXOYTe/P5wDa9ky6no8Xj2PDRmUSZQWk78ryEO4D6apDVJw2UN9LS7+G87m3MR0huzkw0MCYL+Qfsci1Vzt0= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0