Extract Directly from Time Machine
Normally you use Time Machine to restore lost data in a file like this: within the Time Machine interface, you go back to the time the file was not yet messed up, and you restore it to replace the file you have now.
You can also elect to keep both, but the restored file takes the name and place of the current one. So, if you have made changes since the backup took place that you would like to keep, they are lost, or you have to mess around a bit to merge changes, rename files, and trash the unwanted one.
As an alternative, you can browse the Time Machine backup volume directly in the Finder like any normal disk, navigate through the chronological backup hierarchy, and find the file which contains the lost content.
Once you've found it, you can open it and the current version of the file side-by-side, and copy information from Time Machine's version of the file into the current one, without losing any content you put in it since the backup was made.
Series: What the @#$% now?
Need to solve a computer problem and don't know where to start? Start here.
Article 1 of 2 in series
There's no point in pretending that problems never happen. Although this may be a typically male viewpoint, life - computer life and life in general - can be seen as nothing but problems ("challenges," "opportunities") and solutionsShow full article
There's no point in pretending that problems never happen. Although this may be a typically male viewpoint, life - computer life and life in general - can be seen as nothing but problems ("challenges," "opportunities") and solutions. What has always amazed us is the level to which people without much technical experience assume that they can't possibly solve computer problems. Although specialized knowledge certainly helps, troubleshooting is a universal skill. If you can figure out why your brakes are squeaking or why the sewing machine is jamming, you can figure out computer-related problems. Despite what many non-computer people think, there's no real difference.
For those of you who find tracking down and eliminating a problem intimidating, here's a guide that walks you through how I troubleshoot problems of all types. (This article is adapted from the troubleshooting chapter I wrote for the book my friend Glenn Fleishman and I are co-authoring right now, tentatively titled The Wireless Networking Starter Kit.)
The most important piece of advice I can give up front is: Be methodical. If you start trying solutions without thinking about what caused the problem and what the effect of any given solution may be, you just end up complicating the entire situation. The best way to encourage a methodical approach is to take notes about what you see (especially any error messages), what you do, and the effects of what you do.
Describe the Problem -- The first step in troubleshooting is to identify the problem and gather information about it. That sounds simple, and it usually is, because most problems aren't particularly subtle. Perhaps you can't send email, or your one wired computer isn't visible to the computers on your wireless network.
It's important to determine if the problem is reproducible or intermittent. Although an intermittent problem may be less irksome than a reproducible problem if you can keep working through it, intermittent problems are much harder to track down, because one of the variables involved is related to a time- or state-related fact. Reproducible problems almost beg to be solved, because you can't keep working until you've solved the problem.
Pay attention to any visible indicators that might give more information about the problem. For instance, many devices have status LEDs that indicate whether a device is turned on and if it's performing some sort of activity. If those LEDs aren't working the way you expect, record that information.
Break the System Apart -- Once you have a firm grasp on the problem, you need to start breaking the system related to the problem into discrete steps or pieces. Then you can start analyzing different parts of the whole. The hard part here is that you may not realize what the different parts of the system are, making it difficult to understand how one could fail. But if you think about what's involved in using the system, you should be able to determine most of the parts.
For instance, take the example of a wireless network that also has one computer connected via an Ethernet cable. In this sample network, the one wired computer is used as an informal file server. You're using one of the wireless computers, and you suddenly can't connect to a shared folder that's worked fine before. What are the pieces of this system? Let's determine what must be true for the situation to work properly, after which we can analyze each of the components.
On your computer, you need properly installed file sharing client software.
Your computer must have a working connection to the wireless access point.
The access point must allow you to see a computer connected via wired Ethernet.
The wired Ethernet computer must have a working connection to the access point.
File sharing server software must be running on the wired Ethernet computer.
A folder must explicitly be shared on the wired Ethernet computer.
You could certainly break these pieces into even smaller pieces, but this should be sufficient to get started.
Keep in mind that what I've just described is only one working system, which is important, because if there are other working systems - other wireless computers that can see the file server - that can help you zoom in on the problem quickly.
Note all of the pieces of the system briefly in your notebook, and if you're a picture person, consider drawing yourself a diagram of how it all fits together; this can come in especially handy if you actually need to break the system apart by disconnecting cables or rearranging equipment.
Ask Yourself Questions -- Now that you've identified all the parts of the system, it's time to look carefully at each part, making up a possible reason why a failure at that point could be responsible for the whole problem. In our example, let's take each part and analyze it, asking questions that lead to tests.
File sharing client software is of course necessary, but since you were able to connect previously, it's a good assumption that it's installed. Is it turned on? Has anything changed since you last connected successfully that might provide a clue? Have you restarted (it's always worth trying)? What about other computers, both wired and wireless? Can their file sharing client software see the wired computer?
Is the wireless connection to the access point working from your computer? Is it working for other network-related tasks at the same time you can't connect to the wired computer? Can other wireless computers connect to the access point?
Is the access point configured correctly so wireless computers can see the wired computer? Since it worked properly before, this likely isn't the source of the problem. Has anything changed on the access point since you last connected that could be related?
Can the wired computer connect to the access point via its Ethernet cable? (Never underestimate the trouble a broken or flaky cable can cause.)
Is file sharing turned on and configured properly? Has anything changed on that computer that might have resulted in it being turned off or reconfigured? Have you restarted the wired computer recently?
Is the shared folder still shared? Could someone have changed which folders were shared? Has the folder been moved or renamed or otherwise modified in some way that might have changed its state?
I mentioned the difference between reproducible and intermittent problems above; if you have an intermittent problem connecting to the wired Ethernet computer, that generates additional questions.
Does the problem happen at all times of day? Does it happen right after you've done something else? Is it related to the presence or absence of any other machines?
Jot these questions down in your notebook, numbering them so you can easily refer back to them when your tests start providing answers.
Answer Questions -- Once you have your list of questions, revisit it and think about which test you must perform to come up with an answer to each question. Separate your questions roughly into easy, moderate, and hard categories (you might write an E, M, or H next to each question's number in the margin).
Also give your intuition a chance to work. If you have a nagging feeling that your spouse might have let your 4-year-old nephew play a game on the wired Ethernet computer, start with that machine. Or, if you just had to reset the access point to factory default settings for another reason, start there.
Wherever you choose to start, begin with tests that eliminate the easiest questions first. For instance, it's trivial to check if your nephew kicked the Ethernet cable out of the jack; there's no reason to consider reinstalling the entire operating system on that machine until you've exhausted every easier option.
Working methodically is essential at this point, and if you change something in a way that significantly changes the overall system, it's best (if possible) to put it back so the situation stays the same as when you analyzed the problem. For instance, if you had been thinking about installing a new access point that you'd just bought, don't do it in the middle of the troubleshooting process or you risk confusing everything.
Make sure to check off each question you answer in your notebook, and note any interesting things that happen when you perform the test. I don't suggest you do this because you're going to forget what you've done while you're troubleshooting, but because you may have forgotten by the next time the problem happens. Plus, if you end up wanting to ask someone else for help, you can say authoritatively that you had indeed tried some test with negative results.
In most situations, the solution to your problem will make itself clear during this process of answering questions. Perhaps it's summer, and the reinstallation of your screen door is blocking the Wi-Fi signal, or perhaps your spouse configured the computer in an unusual way for your nephew's game. Maybe your access point lost track of the wireless-to-wired Ethernet bridge settings, or maybe your computer or the access point just needed to be restarted.
Get Expert Help -- With truly tricky problems, your tests won't reveal any conclusive answers. Don't feel too bad, because if you've followed the procedure so far carefully, your failing is most likely that you don't understand all the parts of the system well enough. What to do next? Ask for help, of course, and that's where I'll look in the next part of this article.
Article 2 of 2 in series
In the first installment of this article, I talked about the basics steps necessary to troubleshoot any problem, including describing the problem, breaking the system apart, asking yourself questions about each part of the system, and finding answers to those questions and tests. But what if, after all that, you still haven't been able to solve the problem? Failure to solve a problem on your own is no cause for surrender, because you usually just don't understand the system well enough to break it into appropriate chunksShow full article
In the first installment of this article, I talked about the basics steps necessary to troubleshoot any problem, including describing the problem, breaking the system apart, asking yourself questions about each part of the system, and finding answers to those questions and tests.
But what if, after all that, you still haven't been able to solve the problem? Failure to solve a problem on your own is no cause for surrender, because you usually just don't understand the system well enough to break it into appropriate chunks. Or perhaps you simply didn't think of the necessary tests. For instance, in last week's example of not being able to share files between a wireless-enabled computer and a wired computer connected to the same access point, if you didn't realize that all the traffic had to pass through the access point, and a factory default reset (perhaps caused by a lightning strike-driven power surge) had turned off wireless to wired Ethernet bridging, you could easily have tested everything else without realizing what you were missing.
This is where experts come in. Sometimes they may have solved so many problems that they automatically know the solution to your problem based on your description. But more often they can simply break the problem down into more chunks, one of which usually turns out to be the problem.
Intermittent problems can really drive you crazy when it comes time to seek expert help. Although an expert can offer suggestions about where to look, if you have a system that works some of the time, it's very difficult to determine whether you were testing the wrong variables or if you were testing the right variables at the wrong time or in combination with the wrong set of other variables.
Where should you turn first? Give the order in which you jump from expert to expert some thought, since your goal should be to find a solution to your problem with the least effort and cost.
Search the Web -- Before anything else, try searching on the Web, both in company support databases and just generally in Google. The only hard part is coming up with appropriate search terms, but it's worth five minutes of searching if it reveals the answer you need. You wouldn't believe the number of questions we've received over the years whose answers were easily found in Google (since that's where I look first, too).
Of course, if you have any books or magazine articles that touch on the topic, it's worth looking in them as well, though I usually search on the Web first, since it's faster than flipping through an index or scanning multiple issues of a magazine.
Ask an Expert Friend -- If a Web search doesn't turn up an answer, or at least some new tests to try, the fastest, cheapest, and easiest person to ask for help is a friend who is an expert at the topic in question. If you have such a friend, I recommend asking that person for help next. Be careful, though, because overusing a friend's willingness to answer your technical questions or fix your problems can strain otherwise solid friendships. And if the friend is really more of an acquaintance, even more care is warranted to avoid causing irritation.
If possible, try to perform roughly equivalent favors so your friend doesn't feel exploited. Tonya and I even have a "friend consulting rate" for computer help: dinner. That way, the event changes from a consulting visit into a social event with friends, and everyone feels appropriately rewarded.
Contact Tech Support -- If you don't have an expert friend, the next best option is to contact the technical support department run by the manufacturer of the hardware or software in question. If you haven't already done so, visit their Web site and search quickly to see if they have an online database of problems and solutions that can solve your problem instantly.
If that doesn't help, send the company email or call. Company tech support engineers are likely to know more about the products you're using than anyone else, and it's their job to help you if you're a customer (but that doesn't mean you should ever be snotty to them, as I explain below). Contacting tech support is often your best option for getting fast, accurate help.
That's not to say company tech support works well in all situations.
Tech support engineers are often paid badly, so turnover is high and new hires often lack experience, meaning that it's not uncommon to get a tech support engineer who knows less than you do. (In that case, ask politely if your problem can be escalated to second-level support.)
Some companies charge for support, and even when support is free, the calls are seldom toll-free. Unfortunately, it's all too common to wait on hold for 30 minutes before you even talk to a person, and there's little that is more frustrating than knowing that your phone bill increasing while you sit there, not getting your work done. (I usually call on a speakerphone, and read email while I'm waiting, so the time isn't entirely wasted.)
Some tech support engineers may know their products well, but if the problem stems from an interaction between several products, they may not see the bigger picture, or they may try to pass the blame on to another company (which will, in the most annoying cases, pass it back).
Ask on the Internet -- Assuming tech support fails you or isn't worth contacting because of usurious charges or ridiculous phone wait times, the next place to ask is in an appropriate Internet forum. The hard part here is identifying the right place to ask, since so many different groups exist. Check for appropriate mailing lists, Usenet newsgroups, Web-based support forums, and even IRC channels.
When I say "appropriate," I mean it. Watch the forum briefly before posting your question to make sure what you plan to ask fits in with the kind of discussions that go on, because posting an off-topic request for help will irritate people unnecessarily and won't provide you with the solution you need. Plus, it wastes your precious time. Most forums also have a FAQ (frequently asked question) list that may contain the answer you're looking for; be sure to check there to avoid posting a question that the other members have seen numerous times.
Don't be greedy when it comes to asking for help in Internet forums. They work only because individuals are willing to donate their time and knowledge to the public good, so if you want the forum to thrive, be a sport and help others when you can as well.
Hire a Consultant -- If all other avenues have failed, or if you have no time or patience for any of the previous approaches, consider hiring a consultant. Going the consultant route costs the most and isn't necessarily quick, depending on the consultant's schedule and how familiar he or she already is with your situation. But if the problem is sufficiently severe or annoying, the time and money will be well spent.
How to Report Problems -- When it comes time to report your problems to someone else, your notes are invaluable, because without them, you find yourself repeating tests just to verify the results one more time. Obviously, how you report a problem varies depending on to whom you're reporting it, but this approach should work in most situations.
First, create a profile of your computer that lists:
Your model of computer, how much memory it has, and exactly which version of the operating system you're using.
Any recent changes to the system, such as upgrading the operating system itself or installing new drivers.
Special extensions or add-ins installed, like a third-party firewall or, in Mac OS 9, system extensions.
Any add-on devices like a second monitor, third-party video cards, a SCSI card, audio/video hardware, scanners, etc.
Version numbers for software or drivers that are relevant to the problem. Often, outdated or too-new drivers can cause all sorts of problems.
The easiest way to develop a profile of your system is to use Apple System Profiler, which is generally accessible in your Apple menu in Mac OS 9; it's stored in your Utilities folder in Mac OS X. Windows has a similar utility called System Information that's usually in Programs/Accessories/System Tools. Both of these tools let you save a report.
Once you've developed a profile that you can make available if asked, it's time to report the actual problem. Outline your problem briefly and note that you've done standard troubleshooting. Then briefly relate what you've tried already, but don't go into detail right away, since the fact that you're asking for help means that what you tested inherently wasn't right. How you proceed depends on how interactive the support medium is.
For support situations where the medium lends itself to fast interaction - in person, via the phone, instant messaging - let the support person ask questions and guide you through the process, since they likely have ideas about where the problem is. If you launch into a detailed retelling of what you've tried right off, you may overwhelm them with unnecessary trivia. Don't be offended if they ask you about whether lights are lit or the power's plugged in. It can be irritating, but it's their version of methodical problem-solving.
When you're asking for help in a situation where interaction is slow - direct email, mailing list posting, Usenet news posting, or a Web support forum posting - follow your brief summary of what you tried with a more detailed list of the tests you performed and your system configuration. There's no need to explain what happened with each test if it failed to shed any light on the situation, but it is important to list them all so people trying to help don't end up asking about tests you've already performed (in these slow interaction forms of communication, a back-and-forth interchange can take a day or two, so you want to keep the number of messages as small as possible).
In either situation, try to answer questions from the experts as quickly and completely as possible. From our perspective of helping people over the years, there's nothing worse than getting incomplete answers to questions, forcing us to ask the same question in slightly different ways and just stringing out the entire interchange.
Be Nice! Actually, there is something worse than providing incomplete answers to questions, and it's a little hard to say this, but don't be a jerk! You wouldn't believe how many people assume that the problem is somehow the tech support person's fault. Yes, you're frustrated and possibly even angry because of having bought a piece of hardware or software that isn't working, but if you want help, you're far more likely to get it if you're nice, or at least polite and professional, when talking with the tech support person.
Although most people are more polite when they're asking for help in an independent mailing list or other online forum, there's still a tendency to whine or threaten never to buy products from the company again. Bad idea, because the people who are most likely to be able to help you probably like the company and its products, and the more you rant and rail, the less interested they are in responding to you.
Put bluntly, there's a time and a place for complaints, and they should be separated from requests for help. That way you get maximum effect for your complaint and stand the best chance of receiving help.
Dealing with the Insolvable -- I'd like to pretend that if you just follow all of the steps in the previous article and in this one, that you can solve any problem. Unfortunately, there are a very small number of problems that will resist your best efforts, and the best efforts of every expert you can bring to bear. That's because everything you try takes time and effort, and there's a limit to how much energy and money you should invest to solve a given problem. Sometimes the better part of valor really is to give up and buy new hardware or software that eliminates the problem entirely. The hope is, of course, that you realize you're heading down this path before you've wasted too much time and effort.
That said, don't let the fact that some problems really can't be solved with a reasonable amount of effort prevent you from trying. In the vast majority of cases, working methodically through the steps I've outlined in these articles will result in success.
One last note, for those of you who work as the unofficial tech support for your friends, family, and colleagues: I encourage you to send them a link to these articles so they stand a better chance of solving their own problems, or so they can at least be easier to help.
PayBITS: Did Adam's advice save you hours of unnecessary work?
Show your appreciation by sending Adam a few bucks via PayPal.
Read more about PayBITS: <http://www.tidbits.com/paybits/>