April 2008 - Darwin-dev - lists.apple.com

Re: mach-o section question
by Dan Markarian 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hey Cem, http://en.wikipedia.org/wiki/UUID http://www.ietf.org/rfc/rfc4122.txt SHA1Init(&c); SHA1Update(&c, namespc, sizeof(uuid_t)); SHA1Update(&c, name, namelen); SHA1Final(md, &c); uuid_copy(out, md); out[6] = (out[6] & 0x0F) | 0x50; out[8] = (out[8] & 0x3F) | 0x80; } Dan On 21 Apr 2008, at 4:33 PM, Army Research Lab wrote: On 4/21/08 2:34 PM, "Andrew Myrick" <amyrick(a)apple.com> wrote: I'm just not familiar enough with how UUIDs are used to be of much help on this. My guess is it doesn't matter too much, as long as you aren't trying to load the same binary with different UUIDs. For example, in kext land, presume you have 2 kexts, A and B, where B depends on A. In the following scenario: 1) Load kext A 2) Change kext A on disk 3) Load kext B the load will fail because we'll detect the UUID change and flag an error. I would expect that userspace has some similar mechanism, though probably much more complex :) Thanks, Cem Karan _______________________________________________ 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 am not sure whether the Mach-O format requires it, but I suggest you stick to the UUID standard documented in RFC 4122. uuid_generate() follows the standard. You can certainly create a UUID out of some other namespace, per section 4.3, for which I have provided some sample code below. void uuid_generate_name(const uint8_t *name, uint32_t namelen, const uuid_t namespc, uuid_t out) { SHA1_CTX c; uint8_t md[SHA_DIGEST_LENGTH]; OK, so would it be better to use the MD5 hash for the UUID? Its not perfect (collisions can happen), but it will detect the code has changed... _______________________________________________ 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/markarian %40apple.com This email sent to markarian(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach-o section question
by Army Research Lab 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Acij7veANljYNg/iEd2gcQAdT0T19A== Thread-topic: mach-o section question User-agent: Microsoft-Entourage/11.4.0.080122 On 4/21/08 2:34 PM, "Andrew Myrick" <amyrick(a)apple.com> wrote: > I'm just not familiar enough with how UUIDs are used to be of much > help on this. My guess is it doesn't matter too much, as long as you > aren't trying to load the same binary with different UUIDs. For > example, in kext land, presume you have 2 kexts, A and B, where B > depends on A. In the following scenario: > > 1) Load kext A > 2) Change kext A on disk > 3) Load kext B > > the load will fail because we'll detect the UUID change and flag an > error. I would expect that userspace has some similar mechanism, > though probably much more complex :) OK, so would it be better to use the MD5 hash for the UUID? Its not perfect (collisions can happen), but it will detect the code has changed... Thanks, Cem Karan _______________________________________________ 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: kevent and disk eject
by Garth Cummings 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Philip, On Apr 19, 2008, at 5:29 AM, Philip Aker wrote: HTH, --gc ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> WWDC 2008 • June 9-13 • Moscone West • San Francisco, CA <http://developer.apple.com/wwdc/> _______________________________________________ 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 know I can use volume events in Carbon for disk insertion and eject but had hoped to keep things at the same level and eventually move this background app down to a CFRunLoop tool. DiskArbitration is the way to handle disk events at the CoreServices or UNIX layers. It's somewhat light in the documentation department but the headers in DiskArbitration.framework should get you going. The framework is also open source. This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach-o section question
by Andrew Myrick 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- Load commands segment segment segment section 1 section 2 section 3 --- Data otool (1) and nm (1) are also quite helpful. I'm sure it's doable, though it may take some experimenting. I believe that uuid_generate() simply ensures that the UUID is sufficiently random, so you can likely put whatever you want in the uuid_command with the understanding that if you are not actually unique (as much as one can be in a finite namespace), dire consequences may result. 1) Load kext A 2) Change kext A on disk 3) Load kext B Thanks, Cem Karan -Andrew _______________________________________________ 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… As a question is/are the people responsible for keeping "Mac OS X ABI Mach-O File Format Reference" and "Mach-O Programming Topics" on the list? It might help if/when I/we file bugs to be able to point out this whole thread. Since this is an unofficial, unsupported list, there isn't really any way of knowing unless they speak up. It's probably best to include the relevant points in any Radars you file anyway. OK, that was what I thought was going on. The problem is that when I first saw the figure, I thought the following was happening: Hmmm... I guess the first bug I need to file is the need for some fairly complete examples of layouts of mach-o files (sans actual data/ code). I'll do that tonight Well, the only thing I'm thinking about is another long running mental exercise I've had; I'm working out a new (hopefully better) programming language. If I go to the effort of reading/writing the mach-O file format, then I may as well take advantage of it and see if I can't write a compiler to put something into it! :D And, like Objective-C, I'm going to need my own runtime, so it would be nice to be able to do this. Is there any way to determine if there is a collision besides 'dire consequences'? I can think of a few ideas on how to protect against problems, but they require the loader to be notified any time a new mach-O file is loaded onto the system so it can check, and, if necessary, modify, UUIDs for use on a particular system. I'm just not familiar enough with how UUIDs are used to be of much help on this. My guess is it doesn't matter too much, as long as you aren't trying to load the same binary with different UUIDs. For example, in kext land, presume you have 2 kexts, A and B, where B depends on A. In the following scenario: the load will fail because we'll detect the UUID change and flag an error. I would expect that userspace has some similar mechanism, though probably much more complex :) I agree, I'd like to release it someday (assuming I get anywhere with it!) This email sent to site_archiver(a)lists.apple.com

1 0

crash when throwing exception
by Daniel Oberhoff 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Has aynone else had this before? Best Daniel I develop a small machine learning framework for my research on both my linux machine and my osx laptop. Since a while everytime my programs throw exceptions I get a crash, and exclusively on osx. This happens with and without optimizations and the -fexceptions flag. I dont have the exact stack trace right now, but it is always the function unwind_resume_1 that crashes with a bad access to 0x0. I have actually had this before on another project and also only after quite some time of development, so it seems it only happens after the app has a certain complexity. I ignored it then, but currently it really gets annoying, as I use exceptions quite a lot, and the crash makes debugging quite tedious. PS: I hope this is the right list, as I could not find one that suited better. It really seems apple related, as I have never had this on linux (or windows for that matter). _______________________________________________ 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: mach-o section question
by Army Research Lab 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Acij1NC1D1OY7w/IEd2gcQAdT0T19A== Thread-topic: mach-o section question User-agent: Microsoft-Entourage/11.4.0.080122 On 4/21/08 12:49 PM, "Andrew Myrick" <amyrick(a)apple.com> wrote: > Responses inline, with the caveat that my Mach-O experience is > primarily with kext linking and loading, so my comments on user-space > behavior (questions 3-6) are wildly speculative. I hope they are > still of some use. As a question is/are the people responsible for keeping "Mac OS X ABI Mach-O File Format Reference" and "Mach-O Programming Topics" on the list? It might help if/when I/we file bugs to be able to point out this whole thread. > On Apr 21, 2008, at 5:35 AM, Army Research Lab wrote: >> >> I started reading it over the weekend, and have a few questions >> already: >> >> 1) I'm slightly confused by the ordering of sections and segments; >> on page >> 23 of the PDF of the Mac OS X ABI Mach-O File Format Reference (the >> PDF >> complement of the link Andrew sent me above), says that the section >> commands >> for a segment directly follow the segment they are a part of, but >> Fig. 1 >> implies all the segments are grouped together, and then all the >> sections >> follow after that; which is happening? > > Each segment command header is followed directly by its section > _headers_. The figure is somewhat confusing (but correct), because it > considers the section headers to be part of the segment command and > does not illustrate them. The sections that are illustrated are the > section _data_, that is, the data that the section headers describe. OK, that was what I thought was going on. The problem is that when I first saw the figure, I thought the following was happening: --- Load commands segment segment segment section 1 section 2 section 3 --- Data Hmmm... I guess the first bug I need to file is the need for some fairly complete examples of layouts of mach-o files (sans actual data/code). I'll do that tonight >> 2) I know that sections are numbered started at 1; what happens if I >> created >> a section with a number of 0? If I created my own linker, would I >> need to >> reserve space for a section 0? > > Section 0 is reserved for a special purpose. The nlist structure that > describes symbols has an n_sect field which specifies the section in > which a symbol lives. The value 0 is a reserved value called NO_SECT > used for symbols that don't have a section, such as absolute or > undefined symbols. OK, I thought so. >> 3) According to the note on page 12, tools are allowed to define >> addition >> section names; do they need to be registered with Apple in some way to >> prevent namespace problems? > > There isn't a registration requirement that I know if, though perhaps > someone else can chime in if I'm wrong. I would recommend some sort > of prefix to avoid namespace collision. Keep it short since you only > get 16 bytes :) > >> >> >> 4) There is an __OBJC segment; are we allowed to create addition >> segment >> names, or will that throw off the loader? If we can create new >> segments, >> then question #3 can go away, as anything that needs to be tossed >> into its >> own section can go into the segment instead... > > It will probably work just fine (try it and see), but if you don't > need special vm protections or have another compelling need for a new > segment to justify the memory penalty of page-alignment, I would > recommend sticking with a section. Well, the only thing I'm thinking about is another long running mental exercise I've had; I'm working out a new (hopefully better) programming language. If I go to the effort of reading/writing the mach-O file format, then I may as well take advantage of it and see if I can't write a compiler to put something into it! :D And, like Objective-C, I'm going to need my own runtime, so it would be nice to be able to do this. >> 5) The uuid_command referenced on page 20 uses a 128 bit UUID; is this >> expected to be the output of uuid_generate(), or will any 128 bit UUID >> generator work (in short, is there hidden info in the UUID that I >> need to >> keep straight)? > > I believe that uuid_generate() simply ensures that the UUID is > sufficiently random, so you can likely put whatever you want in the > uuid_command with the understanding that if you are not actually > unique (as much as one can be in a finite namespace), dire > consequences may result. Is there any way to determine if there is a collision besides 'dire consequences'? I can think of a few ideas on how to protect against problems, but they require the loader to be notified any time a new mach-O file is loaded onto the system so it can check, and, if necessary, modify, UUIDs for use on a particular system. >> 6) I notice that there are a number of structs (e.g. section, >> defined on >> page 23) that have 16 element char arrays for their section names, >> and the >> docs say ASCII characters; that is a little imprecise, which set of >> characters are allowed? Also, does the string have to be NULL >> terminated? >> More importantly, should all characters that aren't part of the name >> be set >> to NULL? Pure guess suggests that you'd memset() to 0, and then >> only use >> characters for which isgraph() returns true. > > The link editor is likely using standard C-string functions like > strncmp and strlcpy to process these fields, so anything those > functions can deal with is probably safe. However, I would personally > stick to the set of characters that the documented names seem to make > use of, which is [0-9A-Za-z_]. The string should be null-terminated. OK, this is about what I thought I should do. >> In case you're all wondering why I'm asking so many questions, it >> occurred >> to me over the weekend that one of the best ways of learning about a >> file >> format is to make a full reader/writer for it, from scratch. I >> doubt I'll >> really complete such a project, but I'd like to start on it at >> least. My >> goal is to write it in pure Python; that prevents me from cheating, >> and >> thinking I know how something works, when I really don't. It also >> means >> that there will be second implementation of the written standard out >> there, >> which should turn up any bugs in the docs, and may also turn up bugs >> in the >> loader. >> > > It would be quite handy if one could someday "import macho" and profit > from this hard work. Please file Radars against the documentation > whenever it seems incorrect or unclear. Best of luck. I agree, I'd like to release it someday (assuming I get anywhere with it!) Thanks, Cem Karan _______________________________________________ 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: mach-o section question
by Andrew Myrick 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -Andrew _______________________________________________ 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… Responses inline, with the caveat that my Mach-O experience is primarily with kext linking and loading, so my comments on user-space behavior (questions 3-6) are wildly speculative. I hope they are still of some use. On Apr 21, 2008, at 5:35 AM, Army Research Lab wrote: I started reading it over the weekend, and have a few questions already: 1) I'm slightly confused by the ordering of sections and segments; on page 23 of the PDF of the Mac OS X ABI Mach-O File Format Reference (the PDF complement of the link Andrew sent me above), says that the section commands for a segment directly follow the segment they are a part of, but Fig. 1 implies all the segments are grouped together, and then all the sections follow after that; which is happening? Each segment command header is followed directly by its section _headers_. The figure is somewhat confusing (but correct), because it considers the section headers to be part of the segment command and does not illustrate them. The sections that are illustrated are the section _data_, that is, the data that the section headers describe. 2) I know that sections are numbered started at 1; what happens if I created a section with a number of 0? If I created my own linker, would I need to reserve space for a section 0? Section 0 is reserved for a special purpose. The nlist structure that describes symbols has an n_sect field which specifies the section in which a symbol lives. The value 0 is a reserved value called NO_SECT used for symbols that don't have a section, such as absolute or undefined symbols. 3) According to the note on page 12, tools are allowed to define addition section names; do they need to be registered with Apple in some way to prevent namespace problems? There isn't a registration requirement that I know if, though perhaps someone else can chime in if I'm wrong. I would recommend some sort of prefix to avoid namespace collision. Keep it short since you only get 16 bytes :) 4) There is an __OBJC segment; are we allowed to create addition segment names, or will that throw off the loader? If we can create new segments, then question #3 can go away, as anything that needs to be tossed into its own section can go into the segment instead... It will probably work just fine (try it and see), but if you don't need special vm protections or have another compelling need for a new segment to justify the memory penalty of page-alignment, I would recommend sticking with a section. 5) The uuid_command referenced on page 20 uses a 128 bit UUID; is this expected to be the output of uuid_generate(), or will any 128 bit UUID generator work (in short, is there hidden info in the UUID that I need to keep straight)? I believe that uuid_generate() simply ensures that the UUID is sufficiently random, so you can likely put whatever you want in the uuid_command with the understanding that if you are not actually unique (as much as one can be in a finite namespace), dire consequences may result. 6) I notice that there are a number of structs (e.g. section, defined on page 23) that have 16 element char arrays for their section names, and the docs say ASCII characters; that is a little imprecise, which set of characters are allowed? Also, does the string have to be NULL terminated? More importantly, should all characters that aren't part of the name be set to NULL? Pure guess suggests that you'd memset() to 0, and then only use characters for which isgraph() returns true. The link editor is likely using standard C-string functions like strncmp and strlcpy to process these fields, so anything those functions can deal with is probably safe. However, I would personally stick to the set of characters that the documented names seem to make use of, which is [0-9A-Za-z_]. The string should be null-terminated. In case you're all wondering why I'm asking so many questions, it occurred to me over the weekend that one of the best ways of learning about a file format is to make a full reader/writer for it, from scratch. I doubt I'll really complete such a project, but I'd like to start on it at least. My goal is to write it in pure Python; that prevents me from cheating, and thinking I know how something works, when I really don't. It also means that there will be second implementation of the written standard out there, which should turn up any bugs in the docs, and may also turn up bugs in the loader. It would be quite handy if one could someday "import macho" and profit from this hard work. Please file Radars against the documentation whenever it seems incorrect or unclear. Best of luck. This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach-o section question
by Army Research Lab 21 Apr '08

21 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcijrDR3cu7JqA+fEd2gcQAdT0T19A== Thread-topic: mach-o section question User-agent: Microsoft-Entourage/11.4.0.080122 > ------------------------------ > > Message: 2 > Date: Fri, 18 Apr 2008 12:50:49 -0700 > From: Andrew Myrick <amyrick(a)apple.com> > Subject: Re: mach-o section question > To: darwin-dev(a)lists.apple.com > Message-ID: <B8E9F39D-9B68-4E3C-9EB8-DFD1B8C1EEFC(a)apple.com> > Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes > > Send your questions to the list; I'm sure there are a few of us who > have dealt with mach-o parsing before who would be happy to help. > Also, check out this document: > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORun… Reference/reference.html > > While it's not as complete as the headers in /usr/include/mach-o/, it > still contains good information. I started reading it over the weekend, and have a few questions already: 1) I'm slightly confused by the ordering of sections and segments; on page 23 of the PDF of the Mac OS X ABI Mach-O File Format Reference (the PDF complement of the link Andrew sent me above), says that the section commands for a segment directly follow the segment they are a part of, but Fig. 1 implies all the segments are grouped together, and then all the sections follow after that; which is happening? 2) I know that sections are numbered started at 1; what happens if I created a section with a number of 0? If I created my own linker, would I need to reserve space for a section 0? 3) According to the note on page 12, tools are allowed to define addition section names; do they need to be registered with Apple in some way to prevent namespace problems? 4) There is an __OBJC segment; are we allowed to create addition segment names, or will that throw off the loader? If we can create new segments, then question #3 can go away, as anything that needs to be tossed into its own section can go into the segment instead... 5) The uuid_command referenced on page 20 uses a 128 bit UUID; is this expected to be the output of uuid_generate(), or will any 128 bit UUID generator work (in short, is there hidden info in the UUID that I need to keep straight)? 6) I notice that there are a number of structs (e.g. section, defined on page 23) that have 16 element char arrays for their section names, and the docs say ASCII characters; that is a little imprecise, which set of characters are allowed? Also, does the string have to be NULL terminated? More importantly, should all characters that aren't part of the name be set to NULL? Pure guess suggests that you'd memset() to 0, and then only use characters for which isgraph() returns true. In case you're all wondering why I'm asking so many questions, it occurred to me over the weekend that one of the best ways of learning about a file format is to make a full reader/writer for it, from scratch. I doubt I'll really complete such a project, but I'd like to start on it at least. My goal is to write it in pure Python; that prevents me from cheating, and thinking I know how something works, when I really don't. It also means that there will be second implementation of the written standard out there, which should turn up any bugs in the docs, and may also turn up bugs in the loader. Thanks, Cem Karan _______________________________________________ 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: mdworker (spotlight) indexing Time Machine volume
by Achille 19 Apr '08

19 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kIjdNwH1+gJ4TfvoEnDQKo0TltCLHFJqLxL+sDFcqaE=; b=PulZscNjMhnyXvMIUoO1i6zpH2DLUefX2e7rJKU2ELLZkXxHRkcY5q/kUsumNXosC8p4lHLEOiX6e0Nman/Xb/e6GgUfizNGGQ7KhTKBotH6F99ybszvLZGjpveMbs1Ec+SJO3pabhe9zaeNA8ySji9JUveBmqSANBpNvJZc/wE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KJE09mLmCzrm5JRAvDqqokRkDfoLnK1geCe4O4qBkEBqKjRTI9juj8pHW2CDgJLiJe1xG7mm0F5+hyQOUb0u/RZvfTPOGkTXeRnGq3cznQ4xgw6IsCN55HpEaU8HFcYxTv0mxFDkEtJEv+ceW9x4MRXMi2cd3sE4X65mN6qMZ5A= On Fri, Eric Gouriou wrote: > On Fri, Achille wrote: > > > > Spotlight is indexing my time machine drive, which in turn is giving me problems ejecting it. > > > > Trying to turn it off: > > % sudo mdutil -i off /Volumes/Antaeus > > Volumes/Antaeus: > > Indexing enabled. > This disables indexing on the volume index, not on the backup index. > Disabling indexing on the backup itself is not supported. Eric The response from mdutil is incongruent. I expected to see "Indexing disabled", instead i got "Indexing enabled". What are the ramifications If I do succeed in disabling spotlight on that index (ie by preventing access to .Spotlight-V100). * Can't activate time machine on a spotlight search * Anything else? _______________________________________________ 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: mdworker (spotlight) indexing Time Machine volume
by Eric Gouriou 19 Apr '08

19 Apr '08

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