--- ( Your Clicks On Ad Links Help Keep The LangaList Free! ) ---

--------------( the above is an advertisement )--------------

--- ( Your Clicks On Ad Links Help Keep The LangaList Free! ) ---

--------------( the above is an advertisement )--------------

To me, the distinction is clear: Drive Image 7 *MUST* be run from inside Windows. Let me emphasize that: YOU CANNOT MAKE ANY IMAGE IN DI7 WITHOUT RUNNING WINDOWS. Thus, it is a Windows imager, period.

Older versions of DI could run completely independently of ANY operating system or systems installed on the hard drive; and could back up ANYTHING on ANY partition created by ANY OS on ANY hard drive. In short, DI used to be a true OS-independent drive imager. It no longer is. Now, DI7 is an imager only for people running Windows 2000 or Windows XP who also have installed the Windows .Net framework, and whose interest is solely or mostly imaging their Windows partitions: It is truly a limited "Windows imager" now. I don't think this is a false distinction at all--- it's a huge difference in how Drive Image works from earlier versions!

As for in-use/locked files, there are several ways around this, including "shadow copies." This is how XP itself makes backups (including copying of locked or in-use files). It works, but imperfectly: See, for example this http://www.langa.com/newsletters/2001/2001-11-19.htm#3 for how it's supposed to work, and http://www.langa.com/newsletters/2001/2001-11-26.htm#3 for a real-life test I did to show how it can fail. It wasn't a catastrophic failure, but was enough to convince me that shadow copies are not, and cannot be, 100% reliable for full, exact system restoration.

But that's specific to XP's implementation of shadow copying. The next item (below) contains a more general look at the danger that must be overcome by any backup or imaging tool that claims to copy open/in-use/locked files:

Click to email this item to a friend
http://www.langa.com/sendit.htm

return to top of page

3) A Thought Experiment

[continued from above]

Try this simple thought experiment. (It'll only take a minute.)

1) Think of how long it takes to make an image or backup. It could be 2 minutes, 10 minutes, or more--- the actual time doesn't matter. The point is, it's not instantaneous.

2) Now imagine two related files, one (call it "A") near the front of the disk, and one ("B") near the end. They could be system files, a cache or temp or swap files, linked user files (files using a DDE/OLE/XML connection, for example), or *any* kind of file where the content or use or status of one file is influenced by the content, use or status of the other. The exact details don't matter--- it's just a thought experiment.

2a) Relatedly, imagine a fragmented file, where part of the file is at the front of the drive and the rest is at the back.

3) Now imagine you start your image/backup from within Windows. File or fragment "A" is near the front of things, so it gets copied right away. Because the full image/backup will take a while (at least several minutes, and maybe tens of minutes), some time will pass before file or fragment "B" is processed. Meanwhile,  the operating system is awake and still running.

4) Now imagine that a system event or user action modifies file or fragment "A," on the disk, in the normal fashion. The live disk-based file or fragment "A" is now out of synch with the copy in the image or backup, which is still in progress. Meanwhile, file or fragment "B," still uncopied and still on the live system, now updates itself normally or otherwise is modified to be in synch with the newly changed file or fragment "A."

5) Eventually, when the backup/imaging process is ending, file or fragment "B" finally gets copied to the backup or image file.

So, what does this get you? Your hard drive is fine--- the files or fragments "A" and "B" are in synch on your live system, as they should be. But in the backup or image, files/fragments "A" and "B" are incorrect because the "B" portion of the file represents a different time/content/status than "A." In fact, "B" is synched with a later version of "A" that doesn't exist at all in the backup/image! Therefore, if you restore the system from that backup/image file, "A" and "B" may be royally messed up.

OK, I've oversimplified things in this thought experiment, but it illustrates one central conceptual problem with any backup system that runs while the OS is in use.

Is this a high-probability issue? No--- most backups are to protect user data, and most of those files are not interdependent. In fact, most system files likewise stand alone, and thus would NOT be affected by the above scenario. In addition, user and system activity can be kept to a minimum during the backup/image, reducing the odds of important files getting changed in mid-image.

Are there workarounds? Probably--- with sufficient file-locking/tracking intelligence, I suppose a backup/image tool could watch for this kind of activity or fragmentation and re-copy any files that changed during the backup/image process. (There'd be a danger of an endless loop here.)

But if things go well, and if you are careful, and if the laws of probability are in your favor, and if the software engineers worked without error and anticipated all the ways these problems could arise, then your inside-the-operating-system backups/images will be fine.

Now for a dose of reality: Although things can work fine this way, they also can--- and do--- go awry. I refer you again to my real-life experiment that shows how, even with XP's "shadow copy" feature enabled, exactly this sort of file mismatch can and does occur. (See http://www.langa.com/newsletters/2001/2001-11-26.htm#3 ) When this kind of problem happens, the most you can hope for is that your system can be restored to a working state similar to, but not exactly the same as, when the image was created. Sometimes, the differences won't matter. But sometimes, they might.

Now consider: With traditional, true drive imaging, the OS is shut down. No files can change because the OS is not in operation during the few minutes the backup/image takes. File locking, interdependencies and fragmentation are completely irrelevant. It's as if your PC were frozen in time while the hard drive is captured, bit for bit, in that suspended state. No software trickery is needed; no special programming gimmicks are required, and there's no element of playing the odds.

Maybe I'm being paranoid, but I also am too well-acquainted with Murphy's Laws to want to add even a small roll of the dice into my backup process. Rather, I want a method I can use without having to think "I hope it got everything." I want to *know* it got everything--- and that means for me the no quibble, no finger-crossing answer is the classic outside-the-OS image. That's what I use, and that's what I recommend as the top choice for preserving your data and system settings. It's a no-compromise kind of backup.

But I freely acknowledge that my view on backups is extreme--- my livelihood depends on my PC data, after all, and I want to take no unnecessary risks with it. Your mileage may vary, and that's fine too.

Many people have less-stringent backup requirements, so for them, imaging from inside the OS is a perfectly acceptable, "good enough" solution that will do an adequate job of preserving user data and most (though not all) elements of the system state.

At least, with the above thought experiment, you can think about your own situation and decide whether you want and need the no-compromise thoroughness of an outside-the-OS image/backup system, or are OK with the less-stringent inside-the-OS method that may not be as complete.

But no matter what: *Any* backup process is better than none. Just find a method that works for you, and stick with it!

--- ( Your Clicks On Ad Links Help Keep The LangaList Free! ) ---

--------------( the above is an advertisement )--------------

Fred, Find your newsletter tremendously useful. In your continuing discussions of encryption tools ( http://search.atomz.com/search/?sp-q=encrypt&sp-a=0008002a-sp00000000 ), there should be some prominence given to the professional system, PGP. A worry for the paranoid with the various small-scale applications (and let's face it, encryption is about being paranoid) is that there's always the possibility that an author has screwed up or has done something like inserting a "back door" that compromises the product. How can you tell, and unless the author is your brother, how do you really know whether it can be absolutely trusted? PGP is the commercial standard, so it receives a lot of professional scrutiny, and it is still under the watchful eye of Phil Zimmermann, the godfather of contemporary open encryption. And though it is primarily for "public key" encoding, it does conventional file encoding quite straightforwardly as well.

Due to Zimmermann's insistence, it comes in a free version which will do more than most people need. So why not go with the pros?

Of course the company does not make the free version easy to find, but here is the page http://www.pgp.com/products/freeware.html  --Ed Peay

PGP--- which stands for "Pretty Good Privacy"--- is indeed a reputable standard, and Zimmerman's battles with the US Government to keep powerful encryption available to all makes him a tech hero, in my eyes.

But (alas) I've never found the PGP tools as easy to use as some of its competitors', and the PGP company places strict limits on how their free versions can be used. In contrast, some companies offer powerful 256-bit encryption tools based on AES, the Advanced Encryption Standard; many of these tools are offered with far fewer restrictions. (See http://www.informationweek.com/story/showArticle.jhtml?articleID=10100525 )

But it's good to have all the options on the table--- thanks for reminding us of PGP, Ed!

5) Tracking Down Video Problems

Dear Fred, I have a Gateway 2000 PC, which was manufactured in April 1993. The PC lacks a CD drive but has everything else. The only problem is that the monitor does not function properly. When I turn on the PC, I get only a black screen. It does not progress beyond that. I never get to Windows. I am beginning to ask if Windows or other software are even installed on it. What could a monitor that does not process fully mean? How should I fix it? Where should I take it? I've tried contacting Gateway's headquarters in South Dakota and they essentially believe my computer is toast. Could this be true?  Vladimire Herard

Well, it *could* be toast, but you need to try a few things before trashing the system:

Try your monitor on a known-good PC (a second system in your house, or take it to a friend's house, or to work). If the monitor doesn't work on a known-good PC, then the monitor itself is dead and needs replacement.

If the monitor does work, it might be that your video card is dead. If you have a second system with a known-good video card, or a willing friend who'll loan you his card, try that known-good card in your PC. If it works, then it's your video card that's dead and needs replacement.

But if the you get no picture with a known-good card and known-good monitor, odds are it's the system itself. At least then you can replace it knowing that it's truly toast.

--- ( Your Clicks On Ad Links Help Keep The LangaList Free! ) ---

--------------( the above is an advertisement )--------------

Fred, Long time reader - keep up the great work! With all due respect to you, the steps presented in creating the DOS boot disk left out one critical item - a seldom used program called EMM386.EXE. This program must be included in the CONFIG.SYS file with the NOEMS option if you want to load any other program into "high" memory.

You have included this item in boot disks in the past. Being an old CP/M user, I knew something was missing, but couldn't put my finger on it. So I tried your configuration and nothing got loaded into high memory. Then I looked at some of your past articles - sure enough, it was included in "By the Bootstraps" ( http://content.techweb.com/winmag/columns/explorer/1999/1011.htm ), and "Save Your Butt with DOS, Part 2" ( http://content.techweb.com/winmag/columns/explorer/2000/16.htm ). I guess you were rushed this time.

Really enjoy your newsletter - best read I get, and I read a lot of 'em! ---Paul Alexander

No, it wasn't a matter of being rushed. It's that times change:

The NOEMS ("no expanded memory services") switch is useful mostly if you're going to run a pile of old DOS TSRs (terminate-and-stay-resident) or other low memory tools simultaneously: Using NOEMS and RAM, as in:

 DEVICE=EMM386.EXE RAM NOEMS

does indeed help you gain a few extra KB of "low" memory. But a DOS emergency disk is rarely used that way, so the old low memory limits hardly ever come into play any more--- although there were germane in 1999, when the articles you cite first appeared. <g>

There's newer information in "System Setup Secrets" ( http://www.informationweek.com/LP/columnists/langa/2001/03.htm ), which updates those older articles. Using emm386 with newer software can actually *reduce* DOS performance. In most cases today, you do better with just HIMEM, as we discussed in the recent boot disk coverage.

(Note I also omitted other old-time DOS tweaks, such as the "buffers, files=" line in CONFIG.SYS. This is another tweak that mattered in the old days but that really doesn't do much on an emergency boot tool, especially if Smartdrv is loaded, as I suggest in the above.)

Ken Thomson sent in another item:

--- ( Your Clicks On Ad Links Help Keep The LangaList Free! ) ---

--------------( the above is an advertisement )--------------