It's pretty sad that nearly every person I know who loves their iPhone, would nonetheless finish the dangling sentence at the end of the Wall Street Journal teaser (for their interview with AT&T CEO Randall Stephenson) with the clause: "for his resignation."
AT&T CEO: iPhone an Important Part of Line-Up for Some Time [WSJ.com]
When we switched to git last year (from Subversion) we took a little time and beefed up our ignore file. While working on another project recently, I realized that most of the example .gitignore files for Cocoa/MacOSX/XCode on the web are really not terribly complete, and the results can be very frustrating when you're just getting started with a new repository.
Here's a better .gitignore example. Let me know if I left anything out. (I saw a few examples from people who exclude the pattern "profile", but as far as I can tell, that's really not a very good idea. I assume they have a specific use case of some kind which eludes my pondering.)
A better .gitignore for XCode, Cocoa, and Mac OS X git repositories:
# Mac OS X Finder and whatnot .DS_Store
# Sparkle distribution Private Key (Don't check me in!) dsa_priv.pem
# XCode (and ancestors) per-user config (very noisy, and not relevant) *.mode1 *.mode1v3 *.mode2v3 *.perspective *.perspectivev3 *.pbxuser
# Generated files VersionX-revision.h
# build products build/ *.[oa] # Other source repository archive directories (protects when importing) .hg .svn CVS
# automatic backup files *~.nib *.swp *~ *(Autosaved).rtfd/ Backup[ ]of[ ]*.pages/ Backup[ ]of[ ]*.key/ Backup[ ]of[ ]*.numbers/
Both The Register (Rumor rubberizes iPhone 3.0) and Wired (Next-Gen iPhone Specs, Launch Date Revealed) are running iPhone rumor roundup stories.
Both blindly missed two obvious and likely candidates for coming new iPhone features.
Coming a full week before the WWDC 2009 keynote address, this is an amusing ploy to snatch some eye-balls from the traditional Apple rumor-mongering blogs. The rumor blogs typically sum up such rurmors the day prior to major events and garner gazillions of web hits for doing so. Amusingly, both The Register and Wired pitch the expected 3rd generation iPhone as a "minor update", listing rather major interesting potential features while doing so, like video capture, double the memory, 50% improvement in battery life, and other features which would be considered substantial in any other cell phone platform. Oh, they are so bored with technology! Whoa is them!
With each update to Mac OS X, a few people receive an error message from the Apple Software Update utility, similar to the following:
The update "Mac OS X Update" can't be saved.
The digital signature for this package is incorrect. The package may have been tampered with or corrupted since being signed by "Apple".
Here's the screen shot of this message, from one of our beta testers who received this error with the recent Mac OS X 10.5.7 update.
You'll find people posting questions about it to places like Mac Fix It or MacFixIt or Apple's Discussion Forums (such as this item discussion a similar problem with the 10.5.6 update).
In nearly every case, the file was simply corrupted while it was downloaded by the SoftwareUpdate system.
The simplest fix is documented in this tech note: Mac OS X 10.4: Software Update "The digital signature for this package is incorrect" alert
The curious often wonder what directory is used for a download folder the Mac OS X SoftwareUpdate. It turns out that the downloads are stored in a cache which you normally wouldn't need to know about, so it has a cumbersome name, something like this:
/private/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Caches-/com.apple.SoftwareUpdate/swcdn.apple.com/content/downloads/45/37/zzz061-6419/tdJQtVnGYwTmFb7ZHQGgWhm7SDkSwjjqN2/MacOSXUpd10.5.7Patch.pkg
You can find the cache file or the download folder, using the UNIX find command, like this:
sudo find / -type d -name "com.apple.SoftwareUpdate"
or maybe...
sudo find / -type f -name "MacOSXUpd10.5.7Patch.pkg"
But you probably don't need to do that. Just follow the very simple directions at the Apple tech note above instead.
If you're reading this page, it's because you are trying to find good advice on how to recover data from a bad mirrored drive, also known as RAID 1 (zero) on Mac OS X or Mac OS X Server 10.4 (Tiger) or 10.5 (Leopard).
First, as it says on the cover of the good book, don't panic. Take a deep breath, and take your time.
It's very likely that you can recover your data [NOTES 1, 2] in this situation (a probable bad disk in a RAID 1 mirror). The path to doing so is unfortunately not as obvious as it might seem, and not as obvious as it perhaps should be, but it's pretty simple.
Read a whole lot about the subject before you try anything, understand what each tool does before you use it, and then read and think some more before you take the first step.
Now, a bit of background. Typically in such a situation (a bad drive in a RAID 1 mirror) one would expect to be able to "break" the RAID 1 mirror, using the software controls you used to establish the mirror, in this case "Disk Utility.app. DO NOT TRY THIS.
If you value your data:
DO NOT attempt to use Disk Utility.app on Mac OS X to break the mirror, as you may lose data [NOTE 6].
DO NOT attempt to use any "disk recovery" tools until after you have attempted non-destructive recovery efforts [NOTES 4, 5]. Furthermore, if you are working with a "bad" drive which contains the only copy of your data, DO NOT use any "disk recovery" tools until you have cloned the bad drive, and made a copy of the clone. Use the special tools only on the 2nd working copy [7].
DO NOT take your system to the neighborhood PC Doctor style repair shop, DO NOT call the "Geek Squad".
To recover a "bad" RAID 1 volume on Mac OS X or Mac OS X Server 10.4 (Tiger) and 10.5 (Leopard) simply:
Once you identify the good drive you can replace the bad drive and rebuild the mirror. However, I strongly recommend cloning the good disk before you attempt this.
There are a variety of special tools which may help you recover your data, in the event that you are working with one bad drive (rather than one good and one bad, in a mirrored volume). Remember to use dd or Caron Copy Cloner to attempt to clone your bad drive to a good drive, then clone that to a working copy. Only run data recovery tools on a copy of your bad drive, never on the bad drive itself.
Here are some useful tools to help you clone a bad drive without further corrupting the data upon it.
Here are some tools which will help you recover your data, from the working copy of the bad drive which you made using dd, or CCC.
These instructions ignore several things which can in some cases be useful to know. The typical RAID 1 problem presents a situation where one is unlikely to encounter these edge conditions, but for the record, I am not responsible for your data if you follow advice in this email, wether you follow it correctly or not.
For example, (and this is not the only edge case I'm ignoring) in some of the rare cases mentioned elsewhere in this email, attempting to simply mount the drive can result in the operating system attempting a consistency check, and then, if it finds something wrong, a fix. In most cases of RAID 1 problems, this won't make anything worse on the "good" drive, but the "bad" drive could be made worse, as with running any other "disk recovery" tool. The general topic of data recovery is complicated enough that a book and several flowcharts are needed to guide one safely through the minefield with the best chance of data recovery. Unfortunately, that book doesn't yet exist, and the internet is littered with really truly dangerous advice. Even worse, many companies will charge you money to run "Norton Disk Doctor" (or whatever) on your bad drive as their first step, and in some cases utterly destroy a reasonable chance of data recovery.
It's likely that the quickest way to identify the good drive is to just try them. Unplug one, try to boot the system to FireWire Target Disk Mode, then try to mount it to another system, and if that doesn't work, plug it back in and unplug the other. In the case of a bad RAID 1 volume, it's nearly always true that one drive (and filesystem) are good, while the other is bad. You will easily recover your data from the good drive. (See DISCLAIMER).
DO NOT use disk recovery tools, except as a last resort. They are ordinarily not required in this situation. Your RAID 1 volume is nearly always "bad" because one of the hard drives failed. The other drive is almost always OK, with your data intact. In very rare cases one might see the volume itself corrupted, with corruption mirrored to both disks, but one shouldn't attempt to non-destructively diagnose that until after one tries a safer recovery strategy anyway (outlined above, with more advanced details in notes below). Running most disk recovery tools is not a non-destructive act. These tools "recover" a drive by changing the filesystem and data. Running them on a bad hard drive, or on a RAID volume with a bad disk member, can result in data loss.
If one's data is valuable to them, one should never try to use any "data recovery" tools like Boomerang or Norton Disk Doctor on the original "bad" disk or volume, and never until after one has exhausted the "safe" mechanisms for data recovery. These tools can sometimes turn a situation from recoverable to non-recoverable, and should only be used as a last resort, and only after one has (a) cloned the data from the "bad" disk to a good disk, and then (b) made a copy to yet another disk. Only operate such recovery tools against the second copy, so that if and when they blow up, you can attempt to use another tool or another technique from the starting point, rather than from the munged-by-random-poorly-documented-tools point. If you blow up the 2nd copy, you can copy from the good disk to the 2nd copy, and try again. Copying from the original "bad" disk is often time consuming and problematic, so once you have a good dd style copy, clone that for the 2nd, "working" copy.)
On Mac OS X 10.4 and 10.5, as far as I can tell from my own experience, and from the experiences of others some relayed to me directly others revealed by googling, it appears that one cannot reliably use the software controls in Mac OS X Disk Utility to "break" the RAID 1 mirror, as doing so can result in data loss. I personally find the interface for this to be ambiguous, at best. I would not try to break the mirror with the Disk Utility, which *should* be the recommended approach. Several people I know have filed bugs on this, and it has not been improved in years. My system administrator friends now refuse to use Mac OS X software RAID as a result of extensive, and uniformly poor, experience.
If you are performing forensic analysis, or if your data is really valuable, and you don't have a good backup, you can purchase special kits which include a special drive controller. If you need such a kit, you want to make sure that, in addition to addressing your type of drive (IDE, SCSI, SATA, whatever), it will (1) allow you to disable write on the drive with a hardware setting on the kit adaptor, and (2) will attempt unlimited retries of reads until a successful dd can be read from the bad drive. In many cases a very bad drive which cannot be recovered easily can be cloned with one of these kits. If these kits fail, then you'll need the drive to be opened in a clean room by a reputable data recovery specialist to have any hope of data recovery.
You wouldn't be reading this unless you didn't have a good backup of your data. Fix that problem immediately after you recover, or fail to recover, your data. For home users, Time Capsule is a great start to a backup solution.
Twitter and iBlogger can both be considered micro-blogging systems. Somehow, though, I suspect that iBlogger isn't likely to inspire this kind of creative satirical genius. iBlogger isn't sufficiently annoying.
My Twitter nick is: QRandom. Feel free to follow. It's low-traffic, and mostly related to iBlogger.Apple has set an extremely high bar with respect to attention to detail in every aspect of the interface between the company and the customer. Yesterday I purchased an iPod for one of our beta testers, who was also a substantial contributors to iFlinger (an iPhone application that would let you toss a virtual cartoon shoe at a cartoon caricature of former U.S. President George W. Bush, if Apple had approved the application, which they did not.)
Today I was greeted in my email in-basket with a request to fill out a survey. The survey form was efficient and responsive, clear, concise, and contained places for me to elaborate or describe responses which varied from the options on the form. When I finished filling it out, I was greeted with this plain, simple, competently styled web page, which included a minimal set of links to places I might want to go, and a roughly standard footer with other such links, and a thank you.
The pleasant experience with Apple's feedback survey stands in marked contrast with other forms that I've filled out for other companies. Feedback forms always seem to receive the least attention in big companies. Very often they are not well organized, and contain exactly no way to deliver the kind of feedback the company needs to hear.
In these other companies, it's as if the committee in charge of the feedback form is somehow shackled, or has an incentive to gather only positive results, or more likely just doesn't have any experience with conducting surveys, doesn't know much about the company, or just doesn't care. Most of the other online feedback forms I've seen dump you to an oddly unstyled web page, which sometimes says "Thank You" but other times doesn't say anything meaningful at all. Usually they don't include a simple link back to vendor's main web site. I've even seen things like PHP core dumps which left me in no doubt that the vendor really didn't care one iota about my "feedback". Thank you for your feedback! We are promptly tossing it into the bit bucket! Have a nice day!
This almost obsessive attention to detail at Apple, which results in seemingly minor things like the thank you page of the feedback form being considered as an important customer interface, is applied to every possible interaction between Apple and its customers.
Unfortunately, this corporate obsession is not applied to every interaction between Apple and its third party developers. As with similar stories from other vendors, when our iFlinger application was rejected, the reasons offered didn't really make much sense. There was no avenue to provide feedback or make an appeal, or engage in a discussion which might result in the application being modified in such a way as to get approved.
Despite Apple's recent declaration (in the iPhone OS 3.0 presentation) that everything is fine because most apps get approved within a week, now, the iPhone App Store process is hopelessly broken. Developers must guess at what might get approved or rejected, based on a lengthy document full of vague legalize which translates quite literally down to this phrase:
"Apple can reject your application for any reason, for reasons other than stated, to provide them with a fig leaf, or for no reason at all. If a summer intern at Apple rejects your application, tough luck."
To some extent, relations between Apple and their development community have always been rocky. Some tension between them is a natural and unavoidable outcome which arises from Apple's need to keep research and product plans secret. However, the iPhone App Store policies have been upside-down (build it first, we'll tell you later if you will be permitted to sell it) for too long. If it's too difficult to put a concept-approval process in place, then an appeals process needs to be created, and guidance on how to overcome app rejections should be available.
One might be tempted to suggest that Apple's rocky developer relations are their "perfect flaw" but somehow I don't think so. Perfectly flawed pottery doesn't leak water all over the floor.
No, a perfect flaw is more subtle. A perfect flaw is holding your iPhone upside-down, on your otherwise very stylin' iPhone consulting web site.
Posts
All Comments
