September 2006 - Darwin-dev

Out of Office
by SHOWNDE＠slu.edu 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Saint Louis University St. Louis, MO I'm out sick on Wed. Sept. 20. I should be back in the office tomorrow. Please, direct all calls for support to 977-4000 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Where is sysctl.proc_native documented? Other sysctl values?
by Dan Smith 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ls -L [some symbolic linked file] not working
by Mailing list subscriptions 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com El 20/09/2006, a las 12:51, Steve Checkoway escribió: Hard links as implemented in 10.0: http://www.wsanchez.net/papers/USENIX_2000/ Information on hard links (to directories!) in Leopard: http://arstechnica.com/staff/fatbits.ars/2006/8/15/4995 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I disagree. While both of those properties of links are true, I wouldn't say that's the difference. As I'm sure you well know, a hard link is just another link to the same inode with a different path. I know that either HFS or OS X (I'm not sure which) has issues with files that have at any point been hard linked whereas a symbolic link is a different file which points to a path (as can be read by readlink(2)). There is no difference between an original link to a file and a hard link to the file. For all intents and purposes, they are the same file. This is not true of a symlink. HFS+ lacks support in the volume format for hard links, a standard feature of UFS. Initially, the attempted creation of a link to a file would yield a "not supported" error. We had discussed some "80%" solutions, such as creating symbolic links instead, but the semantics of symbolic links are significantly different. For troubleshooting reasons it is preferable to fail at link creation time than at some later time due to problems related to these semantic differences. The problem is that there is a significant amount of software which breaks if hard link creation fails, and some of that software needs to be redesigned if hard links cannot be used. In order to accommodate this software, we now emulate hard links by creating a "kernel-level" symbolic link which is visible only to and interpreted by the HFS+ file system. This was necessary due to the lack of support in the volume format. The resulting behavior is very similar to that of hard links when viewed from above the kernel, though they are relatively inefficient in comparison. Apple added traditional hard links (that is, hard links to files) to HFS+ back before Mac OS X 10.0 was released. In Leopard, HFS+ supports hard links to directories as well—an ability wholly alien to any other Unix-like operating system that I can think of. This is how Time Machine builds its sparse trees. The very first backup is a full copy. All subsequent backups contain hard links to the unchanged portions of the previous backup. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ls -L [some symbolic linked file] not working
by Steve Checkoway 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 20, 2006, at 12:48 AM, Pelle Johansson wrote: - the difference between a symbolic and a hard link is mostly in implementation (the former gets you cross-device linking, and can "break"; the latter is confined to one device and won't break). -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com Justin C. Walker wrote: The idea is that you can refer to the collection of bytes that works out to "hello world\n" by the name 'foop' and I can refer to it as 'goop', and we really don't know that those two different names are the same file (unless we do some detective work (using 'ls')). If you type "ls -lL foop", you get the information about the file; the name remains the same because that is how you refer to it. I'd suggest everyone who thinks this is confusing read the stat(2) manpage and consider that without -L lstat is used, but with it stat is. I'm well aware of how files and links work and I know the difference between lstat and stat. My objection was to the man page. I think the gnu man page more accurately captures the distinction. After all, passing -L to ls does nothing without -l. After all, what does it mean to "list" a file if not to display the name? The -l option is for listing in the long format. On Sep 19, 2006, at 8:18 PM, Justin C. Walker wrote: I disagree. While both of those properties of links are true, I wouldn't say that's the difference. As I'm sure you well know, a hard link is just another link to the same inode with a different path. I know that either HFS or OS X (I'm not sure which) has issues with files that have at any point been hard linked whereas a symbolic link is a different file which points to a path (as can be read by readlink (2)). There is no difference between an original link to a file and a hard link to the file. For all intents and purposes, they are the same file. This is not true of a symlink. To quote from symlink(7), "A hard link to a file is indistinguishable from the original file because it is a reference to the object underlying the original file name." "A symbolic link contains the name of the file to which it is linked, i.e. it is a pointer to another name, and not to an underlying object." smime.p7s

1 0

Re: ls -L [some symbolic linked file] not working
by Pelle Johansson 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Justin C. Walker wrote: The idea is that you can refer to the collection of bytes that works out to "hello world\n" by the name 'foop' and I can refer to it as 'goop', and we really don't know that those two different names are the same file (unless we do some detective work (using 'ls')). If you type "ls -lL foop", you get the information about the file; the name remains the same because that is how you refer to it. I'd suggest everyone who thinks this is confusing read the stat(2) manpage and consider that without -L lstat is used, but with it stat is. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: leopard *.dmg file too big
by Eric Schlegel 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 19, 2006, at 7:44 PM, Ted Thibodeau Jr wrote: This information is not specific to Leopard seeds, about which I have no specific comment or information DVD+R DL is necessary for 4.71-9.4 GB images. This media size is necessary for more than 120 minutes of DVD video, too -- with the new disc capacity being 240 minutes. These are burnable in the latest Mac-included SuperDrives, but not in all older ones. (I do not have any information on which models started including the newer drives, but it was not later than the Intel-based iMacs.) -eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Optionally, if you have a free partition on any attached drive that's big enough, you can just write the .dmg to the hard drive partition rather than burning a DVD. This is common practice for many Apple engineers. Then you can boot from that partition rather than booting from the DVD. It's typically much faster than burning a DVD, too. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ls -L [some symbolic linked file] not working
by Justin C. Walker 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 19, 2006, at 19:12 , Steve Checkoway wrote: $ ls -l foop lrwxr-xr-x 1 justin wheel 9 Sep 19 18:59 foop -> /tmp/goop you see the *file information* for the linked-to file, as in $ ls -lL foop -rw-r--r-- 1 justin wheel 7 Sep 19 18:59 foop This really is the correct behavior, and it is the way links work. Hope that is clearer. Justin -- Justin C. Walker, Curmudgeon-At-Large Director Institute for the Enhancement of the Director's Income -------- "Weaseling out of things is what separates us from the animals. Well, except the weasel." - Homer J Simpson -------- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Sep 19, 2006, at 20:01 , Steve Checkoway wrote: On Sep 19, 2006, at 7:24 PM, Justin C. Walker wrote: I think the issue is that this behavior seems to contradict what the man page says: -L If argument is a symbolic link, list the file or directory the link references rather than the link itself. This option cancels the -P option. I think if you read that correctly (i.e., the way I do :-}), it says that instead of seeing the *file information* for the symlink, as in I read it as saying that if the argument is a symlink (as is foop below), then it will list the file or directory the link references (goop in this case), rather than the link itself. I'm not sure how else to read that. As I did. The key is in what "list the file" means, and I take it to mean the information about the file, not the file name. In this case, it's showing the metadata of goop as being the metadata of foop and not even showing that foop is a symlink. This seems even worse. The file information in Unix file systems is divorced from the file name. Well, I'm not using UFS here, but I know what you're saying. I'm really not sure how you managed to read the man page in that way. Keep in mind, I quote the BSD man page, not the GNU man page (of which I seem to have two different versions) which does mention file information. These are Unix command line tools, and whether it is UFS, HFS, or another brand of file system, if links are supported, this is how they behave: - the directory entry for a file (of whatever type) consists of the name and a hook of some kind to get at the metadata, to use your word. - that information (metadata) is separate from the file name - links provide you the ability to have many names for the same file - the difference between a symbolic and a hard link is mostly in implementation (the former gets you cross-device linking, and can "break"; the latter is confined to one device and won't break). The idea is that you can refer to the collection of bytes that works out to "hello world\n" by the name 'foop' and I can refer to it as 'goop', and we really don't know that those two different names are the same file (unless we do some detective work (using 'ls')). If you type "ls -lL foop", you get the information about the file; the name remains the same because that is how you refer to it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ls -L [some symbolic linked file] not working
by Steve Checkoway 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Sep 19, 2006, at 7:24 PM, Justin C. Walker wrote: On Sep 19, 2006, at 19:12 , Steve Checkoway wrote: $ ls -l foop lrwxr-xr-x 1 justin wheel 9 Sep 19 18:59 foop -> /tmp/goop you see the *file information* for the linked-to file, as in $ ls -lL foop -rw-r--r-- 1 justin wheel 7 Sep 19 18:59 foop -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com I think the issue is that this behavior seems to contradict what the man page says: -L If argument is a symbolic link, list the file or directory the link references rather than the link itself. This option cancels the -P option. I think if you read that correctly (i.e., the way I do :-}), it says that instead of seeing the *file information* for the symlink, as in I read it as saying that if the argument is a symlink (as is foop below), then it will list the file or directory the link references (goop in this case), rather than the link itself. I'm not sure how else to read that. In this case, it's showing the metadata of goop as being the metadata of foop and not even showing that foop is a symlink. This seems even worse. The file information in Unix file systems is divorced from the file name. Well, I'm not using UFS here, but I know what you're saying. I'm really not sure how you managed to read the man page in that way. Keep in mind, I quote the BSD man page, not the GNU man page (of which I seem to have two different versions) which does mention file information. smime.p7s

1 0

Re: leopard *.dmg file too big
by itojun＠itojun.org 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com > > i'm signed up to apple software seeding program for leopard. > > the disk image file currently online exceeds 4.7Gbytes, so it does not > > fit normal DVD-R. any workarounds/helps are appreciated. thanks. > Read the documentation that comes with it... ok, i need double-layer DVD-R. thanks. itojun _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: leopard *.dmg file too big
by Ted Thibodeau Jr 20 Sep '06

20 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com * Jun-ichiro itojun Hagino [2006/09/20 11:27 AM +0900] wrote: > i know this is not the right forum to ask, but i guessed i could > get answer here, so... > > i'm signed up to apple software seeding program for leopard. the > disk image file currently online exceeds 4.7Gbytes, so it does not > fit normal DVD-R. any workarounds/helps are appreciated. thanks. > > itojun I'm answering to spare the list needless discussion and repeats of this and similar questions. This information is not specific to Leopard seeds, about which I have no specific comment or information DVD+R DL is necessary for 4.71-9.4 GB images. This media size is necessary for more than 120 minutes of DVD video, too -- with the new disc capacity being 240 minutes. These are burnable in the latest Mac-included SuperDrives, but not in all older ones. (I do not have any information on which models started including the newer drives, but it was not later than the Intel-based iMacs.) You can check whether your Mac can burn the DL (dual layer) DVD+R by reviewing the System Profiler output for burning capabilities, in either GUI or command-line tools. Note that you need specific DL media as well as the new burner. DL images cannot be split across two single-layer discs. Be seeing you, Ted -- A: Yes. http://www.guckes.net/faq/attribution.html | Q: Are you sure? | | A: Because it reverses the logical flow of conversation. | | | Q: Why is top posting frowned upon? Ted Thibodeau, Jr. // voice +1-781-273-0900 x32 Evangelism & Support // mailto:tthibodeau@openlinksw.com OpenLink Software, Inc. // http://www.openlinksw.com/ http://www.openlinksw.com/weblogs/uda/ OpenLink Blogs http://www.openlinksw.com/weblogs/virtuoso/ http://www.openlinksw.com/blog/~kidehen/ Universal Data Access and Virtual Database Technology Providers _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0