June 2006 - Darwin-dev - lists.apple.com

Re: Re: USB driver vendor id/product id list?
by Brian Bechtel 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(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:content-transfer-encoding:content-disposition:references; b=q+VwuKg8Xuk+/zqat2dqkap2PrsSdLDrPem3vp6SmP6fhxTyX/2c70U+jz4g3WpNnPuQ+Z4wvYFF4DG22B4u+LO5+aVDrvqmqBj5rQMWrUAKBrSJubrpu5akXo/zRIluP4RPXWvlo/cd5o/FRtql7IobraGu5DurOKyZO0srxFc= I believe it is up to the vendors to ensure product ids are unique. I do now know who ensures vendor ids are unique. Perhaps the USB-IF, www.usb.org. Yes. <http://www.usb.org/developers/vendor/> has details _______________________________________________ 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 6/26/06, Matthew Owings <matt(a)qwizdom.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

sendmail 8.13.7 build error
by William M. Davidson 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.2.5.1i I am attempting to install sendmail 8.13.7 on MacOS 10.4.6 (Darwin 8.6). I have looked at the FAQ at sendmail.org but did not see anything regarding my problem. The build process almost works. The build generates: cc -pipe -o sendmail main.o alias.o arpadate.o bf.o collect.o conf.o control.o convtime.o daemon.o deliver.o domain.o envelope.o err.o headers.o macro.o map.o mci.o milter.o mime.o parseaddr.o queue.o ratectrl.o readcf.o recipient.o sasl.o savemail.o sfsasl.o shmticklib.o sm_resolve.o srvrsmtp.o stab.o stats.o sysexits.o timers.o tls.o trace.o udb.o usersmtp.o util.o version.o /usr/share/sendmail/obj.Darwin.8.6.0.PowerMacintosh/libsmutil/libsmutil.a /usr/share/sendmail/obj.Darwin.8.6.0.PowerMacintosh/libsm/libsm.a /usr/bin/ld: Undefined symbols: _kdb2_dbopen collect2: ld returned 1 exit status make[1]: *** [sendmail] Error 1 Because of the undefined symbol, the executable is _not_ made. The same undefined symbol is reported for all of the other sendmail executables (editmap, makemap, vacation, etc.) My only guess is to search the archive file (.a) one more time. However, I am unable to locate the .a file that defines _kdb2_dbopen. Any and all suggestions will be appreciated! -- William M. Davidson grateful(a)nmia.com 1704 Blume, NE Albuquerque, NM 87112 505 294 4571 Too many people spend money they haven't earned, to buy things they don't want, to impress people they don't like. -Will Rogers _______________________________________________ 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: USB driver vendor id/product id list?
by Matthew Owings 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcaYifOC910tYxxxTMeHJQBkeXc46QArcKQw I believe it is up to the vendors to ensure product ids are unique. I do now know who ensures vendor ids are unique. Perhaps the USB-IF, www.usb.org. > Message: 1 > Date: Sat, 24 Jun 2006 12:17:24 -0700 > From: "Brian Bechtel" <brian.bechtel(a)gmail.com> > Subject: Re: USB driver vendor id/product id list? > To: " Andr?-John Mas " <ajmas(a)sympatico.ca> > Cc: "darwin-dev(a)lists.apple.com" <Darwin-dev(a)lists.apple.com> > Message-ID: > <f6b4217c0606241217r7cce0532k95b3be190339fa0e(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 6/24/06, Andri-John Mas <ajmas(a)sympatico.ca> wrote: > > Would it be feasible a) for Apple to compile a list > > No, I can't see how or why Apple would do that. Too much effort for > too little return. Apple wants their developers to make money. > > > or at least > > provide one where people > > could add entries > > That's <http://www.pcidatabase.com> > > > and b) for a tool to be provide to MacOS X to > > actually look up this > > information. > > That's "ioreg -l" in a terminal window. System Profiler also provides > this information. _______________________________________________ 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: dynamic playlist in dss
by Finlay Dobbie 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HQwShLLui4cfM58ptFDHU4RS2hSxaFYdp9ESQ0+Xaf+PtcjscdSKcH1mMm69U4G3I7OCN1X/GgLxVhibrkeR2fy2xAKjqwSeD85rmQ1amOPTwpS2EMUa7qi8FQ3bNYIXeM/EZ4Wn2jB/5NDoxd3lZu572VxkyBjMu1nOUizpQZI= Here's the right list: <http://lists.apple.com/mailman/listinfo/streaming-server-dev> Actually, try <http://lists.apple.com/mailman/listinfo/streaming-server-users> ;-) -- Finlay _______________________________________________ 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 26/06/06, Eric Albert <ejalbert(a)apple.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Finlay Dobbie 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KvXwjFo4WJh8emJ9jkGU0cxQJvd9PSViODOGSTSZj5W7AlknpeZWB3b14DixYUrUHarLuUTZLxrsUcbnDxV5IYoczxG7+88fWV3Q6e8ntJWVbey196KVtSK+io2aRg4H5MgoPXbPgpGd32d8UQv1alswNRnFIp1hBjRQeT9A804= The biggest issue for users that I have observed with not associating "extra" data (like iPhoto categories) with the file data is that it gets lost if the file gets moved or copied by any application other than the one with the disassociated metadata. For applications like iTunes this works as expected, as it places it's associated attributes within the file data. But for applications like iPhoto which keep a secondary database of associated metadata rather than directly pairing it with the file data itself, copying the file doesn't preserve any of this extra metadata. Well, with iTunes you'll find the situation is even more confusing than that, since some items (play count, ratings?) aren't stored in the ID3 tags in the file but only in the iTunes DB, and *will* get lost if you move the file. -- Finlay _______________________________________________ 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 26/06/06, Q <qdolan(a)gmail.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: dynamic playlist in dss
by Eric Albert 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 26, 2006, at 3:21 AM, Roberto Cruz wrote: Here's the right list: <http://lists.apple.com/mailman/listinfo/streaming-server-dev> -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… This is not the best list to ask for this Actually, this is the wrong list to ask this. This list is about Darwin, the lower-level components of Mac OS X, not Darwin Streaming Server. From the description of this list at <http:// www.lists.apple.com/mailman/listinfo>: "Technical discussion list for general Darwin software development. This does not include Carbon, Cocoa, or Darwin Streaming Server." This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by maurits 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Quinton, Cheers, Moritz -- http://www.plasticsfuture.org _______________________________________________ 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… In a nutshell, what the average Mac user expects is for a file's metadata (eg, comments, tags, colours, groups, keywords, etc), regardless what application it's related to, to be preserved when it gets moved/copied/backed up no matter where it ends up. while I pretty much agree with you, I guess we need to be a bit more precise. IMO, you're preaching to the choir (or barking up the wrong tree, depending on how you see it): The Darwin team has done everything to make the standard BSD tools support HFS+ extended attributes, and it works great (except some regression in 10.4.6's ASR, and outdated tools such as ditto and CpMac). Finder also copies EAs. An entirely unrelated question is what to do with the EAs, and that's certainly not in the hands of the Darwin folks. Everything is in place, and I, too, think that applications should make widespread use of EAs to store metadata such as tags, categories, etc., because a user would expect to have that information attached to a file and not buried in some application-specific database (speaking, for example, of the "black hole" that iPhoto libraries are). So Apple should definitely be encouraged to be a role model in this sense with their iApps. But I don't even think they can be blamed for not using EAs extensively in Tiger, because it would certainly have been negligent to use a freshly introduced API until it has matured and until there is a wide user base that supports these APIs. With Leopard, however, I would certainly hope that EAs will actually be put to use. Standardized methods for tagging and attaching metadata attributes in combination with Spotlight - that has the potential for being hugely useful. Again, that's all not a matter of Darwin or the BSD tools - the homework is done there. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Marc Epard 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcaZJJq02V3sTgUXEduXqAANk21umg== Thread-topic: Metadata support User-agent: Microsoft-Entourage/11.2.4.060510 on 6/26/06 1:46 AM, Jordan K. Hubbard wrote: > I believe the creation date is not > something you're intended to spoof - it's when the file was created. > If you create a backup file, that backup file will have its own > creation date. If you restore from backup in such a way that the > original file is deleted and replaced (e.g. a new inode is allocated) > then, by all rights, the new file is not the same as the old file and > should have its (newer) creation date reflect this. FWIW, this > behavior is not unique to MacOSX. I can see how you would think this way from an implementer's point of view. Certainly to duplicate or backup a file, the implementation must create a new file to copy the old file's contents into. However, from an end user's point of view, this is not intuitive at all. A duplicate of a file should no more have its own creation date than a photocopy of a letter should receive a new date. It would be nice if a duplicate/backup copy incorporated *additional* metadata regarding the duplication date history, but the creation date, as well as other metadata, should be preserved. I ought to be able to make a backup copy of a file or folder with the tool of my choice, then replace (restore) the original with the backup and all metadata should be restored. Perhaps it might add information that the two copies happened, but at the least it ought to get me back to where I started. This is the behavior of traditional Mac OS and of the current Mac OS X Finder. Other utilities ought to do the same. -Marc _______________________________________________ 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: dynamic playlist in dss
by Mats Eriksson 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcaZCkw6OzvEhyL/R+yyai2t+7N29AAAdQdQ Thread-topic: dynamic playlist in dss _______________________________________________ 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: Metadata support
by Q 26 Jun '06

26 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Y5nMYeqgCxqjCSSZuYZxwzOXtRQudoOdrqRAnfgJ2vaSby933XFXnqwnWI+h6MdbA14ufwGTTB2XztAnWgplSdipV1zUTEUC1c1LL6sP3hwomIL7qJZfkrbs+2UX1QCVYnu5K93VzxlO0SZtAVsn1DEL0H4MELlMBd2SJmcehJ4= On 26/06/2006, at 11:02 AM, Jordan K. Hubbard wrote: Agreed. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _____ / Quinton Dolan - qdolan(a)gmail.com __ __/ / / __/ / / / __ / _/ / / Gold Coast, QLD, Australia __/ __/ __/ ____/ / - / Ph: +61 419 729 806 _______ / _\ _______________________________________________ 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 think there's been a lot of confusion here about what constitutes "file metadata". First off, the ownership/mode/{creation,access} time and other inode specific data is POSIX-layer stuff and there already exist [l] stat(2) interfaces for getting this information, so sticking it in the EA list would be double-entry bookkeeping at best and confusing at worst. Second, you can hardly include "3rd party housekeeping" info like Finder's .DS_Store data in the same category since that's just some other application's view of the file, it's not data specific to the file itself. Another instance of that would be spotlight's index data for the file - would you have that associated with the file too? What about other applications? The biggest issue for users that I have observed with not associating "extra" data (like iPhoto categories) with the file data is that it gets lost if the file gets moved or copied by any application other than the one with the disassociated metadata. For applications like iTunes this works as expected, as it places it's associated attributes within the file data. But for applications like iPhoto which keep a secondary database of associated metadata rather than directly pairing it with the file data itself, copying the file doesn't preserve any of this extra metadata. Admittedly associating application metadata with file data raises the question of how to deal with other issues like how to do proper housekeeping, ownership and authority of attributes, eliminating duplication, etc. But this is a secondary concern for most users confronted by unexpected data loss. Ultimately, trying to associate all of this goop with the file itself represents a gross layering violation and something that's downright perilous to do for all sorts of application / file syncing reasons I won't go into here. True, but it really depends on how this association is made. Sure this goop may not belong as raw extended attributes, but it's something that a lot of users expect the OS (not the application) to just know how to handle. One thing worse than not being able to have file metadata is not being able trust that it will be there if you copy/move/backup the file. What are you folks actually trying to do? Have you considered that it might be the wrong thing? :) Having spent some time trying to deal with syncing of file data, metadata and filesystem data on tiger ( http://www.onthenet.com.au/~q/ rsync ) I have received plenty of emails from people confused by the differences between what they expect to happen and how the system and applications concerned actually work. Pretty much all the confusion has revolved around application metadata like Finder's .DS_Store or iPhoto's library catalogue, etc. Spotlight only helps to further confuse things because it hides a lot of what is actually going on under the skin. In a nutshell, what the average Mac user expects is for a file's metadata (eg, comments, tags, colours, groups, keywords, etc), regardless what application it's related to, to be preserved when it gets moved/copied/backed up no matter where it ends up. So that you can open it up at a later date or on a different machine and expect to see that it and all it's associated metadata is still intact. They don't want to have to worry about secondary databases and the like, if they can see the file, and drag & drop it, they want EVERYTHING about that file to go along with it. Which comes back to the issue highlighted in your previous statement. Any application can have different ways of viewing or attributing a given file. The problem with this kind of disassociated metadata is that it's not actually associated with the file data at all, but instead the filesystem's representation of the data as a filesystem record (ie. the file or folder record). On top of that, each application has to do it in its own way. So there is no way for a system tool, (or 3rd party tool) to selectively copy files and their associated application metadata. The only way is to use the application in question to backup/export the files, which means you can never have more than one application's attributions preserved during the copy process. If instead of maintaining their own disassociated databases, applications were able to use some system provided framework to store and retrieve application metadata for a file, similar to resource forks, but stored by whatever means the OS chooses (spotlight, appledouble files, extended attributes, whatever). This would go a long way to being able to help solve this type of problem as it places the operating system back in control of the data, and provides a known, defined method for managing it when changes are made to the associated file data. The upside of this is you get spotlight searchability for free. Sorry for the rant, I got a bit carried away.. but this has been bugging me for a while. This email sent to site_archiver(a)lists.apple.com

1 0