Hiya  :)


° using boot floppies in DOS only!

Lately (the last 3 images of XP SP3 - system partition only) I experienced the following:
Creating an image to HDD went fine.

When I wrote it on a single* DVD (after the above) > compression high, after the writing process Ghost 2003 shows:
total MB = (e.g.) 6610 | leftover MB = - 14.
Then Ghost shows message "successful", and it corrects to the actual** size = 6596MB.

* = 1 DVD (4.7GB), still a little free space. Although Ghost tells me at the beginning "2 DVDs needed" how come ???. I never needed 2 so far --> (Of course, XP size is getting bigger & bigger).

** = size that was shown when creating img to HDD.

My question:
Since I experienced the "- 14MB" (although the MBs were set to the actual size after the message "successful") when creating the last 3 images, >>> are those images possibly incomplete  :-?

henriette < worried>

@ henriette


Quote:

are those images possibly incomplete

Well, the *gold standard* to make sure an image file is a good one is to run an *Integrity* check right after the creation of the file.  If it passes the *Integrity* check, then you can have a much higher level of confidence that all is well--still not a *guarantee*, but you should be okay.

I run the *Integrity* check on all my images--but, especially it should be done on optical disc images--over the years that has been the lesser reliable image backup media.  On my systems, optical media has never been a problem--but, we have seen more reports here of others running into problems.

And, the most common issue was not doing an *Integrity* check, and assuming that the image file was okay.  If you know there's a problem from the beginning with an image file, you can do things over, and hopefully correct any issues.  But, if you wait until the last moment, and then try to restore from optical media, and the file is corrupt for any reason--well, that's too late!

Again, on my systems, I have never experienced a problem with optical images reporting being corrupt at some point in the future if they have passed that initial *Integrity* check.

My time is limited this morning--I have a couple other comments, but those will have to wait until later.

@ henriette

When you create your Ghost backup to the HD, what size are the images created by Ghost 2003? What are the file extensions?

My experience is that Ghost 2003 has problems calculating large file sizes, above 4 GB I think and in that respect  pagefile.sys and hiberfil.sys. Those two files have become large with the sizes of RAM installed today. They are system files that are excluded from the image and Ghost 2003 doesn't get it right when calculating.

I have "only" 4 GB RAM with a pagefile set to a minimum size of 1.5 x RAM = 6 144 MB.  Hibernation is disabled (no hiberfil.sys.). While creating the most recent image (yes, I take notes) Ghost said that used space was 13809 MB but the image ended up being 7665 MB, 6144 MB less.

So, my guess is that your missing 14 GB are probably those two files. (With a Windows managed pagefile, you never know how large it is. It shrinks and expands but one thing is certain, it is there.) In concequence, I think that your images are complete but as suggested by oters, run an integrity check!

@ NightOwl
I always run an *integrity* check on all images, both HDD and optical drive ;)

Thank you, anyway, for reminding me. [can't be said often enough] :-*


@ Brian


Quote:

backup to the HD, what size are the images created by Ghost 2003

= what I'd called the °actual° size. Equal to what I get at the end on DVD (see my post #1).


@ Christer


Quote:

Ghost 2003 has problems calculating large file sizes, above 4 GB I think and in that respect  pagefile.sys and hiberfil.sys. Those two files have become large with the sizes of RAM installed today. They are system files that are excluded from the image and Ghost 2003 doesn't get it right when calculating. So, my guess is that your missing 14 GB are probably those two files.

That's very interesting, Christer, thank you.

Thank you all for your help  [smiley=thumbsup.gif]

henriette <relieved>  :)

@ henriette

Okay, so some additional comments:


Quote:

after the writing process Ghost 2003 shows: total MB = (e.g.) 6610 | leftover MB = - 14

I've never seen that before--so not sure what that represents--but must be some sort of *housekeeping* being done at the end of the backup.

For instance, if you look at the Ghost image files saved to the HDD, you will find that the file with the most recent time/date stamp is going to be the first xxx.gho file, and not the last xxx.ghs file.  That's because Ghost writes to that first file when everything is done some sort of information about the completion of the backup.  When you save that same data to a DVD, that first xxx.gho file can not be modified like the one on the HDD can be.  So, now that end of backup information (whatever that may be) is saved to the last xxx.cda (I can't remember--is that the correct Ghost .3 after the file name for optical files?) as can be verified by looking at the time/date stamp for the file.  (Also, if you load an image file that's saved to optical disc using Ghost Explorer, you are asked to insert the first disc, and then the last disc so Ghost can read the first .gho file and then the last file on the last disc for the end of procedure information.)


Quote:

* = 1 DVD (4.7GB), still a little free space. Although Ghost tells me at the beginning "2 DVDs needed"  how come ???. I never needed 2 so far

When Ghost starts a backup procedure, it looks at the total amount of MB's it will be backing up.  Different file types can be compressed more, and other file types are already as compressed as they can be.  Ghost is programed with a built-in *gestimate* as to what percentage of those backup MB's can be compressed--it's only an estimate.  The program doesn't *know* how much space will actually be saved until it has actually gone through the process and compressed all the files that it can.

So, initially, Ghost *estimates* it will need two discs.  But, you must have more files that compress better than what Ghost is estimating--so you actually end up needing just the one disc for now.  But, you can assume that you are nearing the limit of what will fit on one DVD--unless you delete some programs or data files to reduce the MB's.

@ NightOwl


Quote:

...but must be some sort of *housekeeping* being done at the end of the backup.

Yepp ;D


Quote:

I can't remember--is that the correct Ghost .3 after the file name for optical files?)

Sorry, can't do much multitasking for the time being. Will tell you later if that's important to you. OK ?


Quote:

Ghost *estimates* it will need two discs

 
Yepp. 


Quote:

you can assume that you are nearing the limit of what will fit on one DVD

That's exactly why I posted, and what I was afraid of... just for a few MBs  ::)

I checked & checked ... can't delete/uninstall progs (needed!). Got CCleaner + TuneUpUtilities ++ to keep my PC as clean as possible.

Will Ghost definitely ask me for a second DVD if necessary  :-?

The thing is:
1. No Ghost explorer possible anymore, when more than 1 DVD.
2. Will restore from two DVDs work without problems ???

Please note:
° I always make the DVDs bootable!!!!! - (what size has the *boot.exe* ???)
° Mind, I want to keep XP after 2014!!! Therefore it's got to be bootable (security reasons > DOS!).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Christer posted


Quote:

... your missing 14G!!B are probably those two files.

(see below) ... or is it me *counting wrong* today > GB/MB  :-?


The *pagefile.sys* on my PC = 2097MB (2GB RAM). *hiberfil.sys* does not exist, since 'hibernation' is disabled.

Please note:
1. Creating and integrity check > image to HD (size last img BOTH = 6596MB --- no calculating problems of Ghost!

2. Writing and! integrity check > image DVD = 6596 after Ghost "corrected" the -14M!!B, in both cases.

So the reason for the calculating problems of Ghost 2003 is the fact that I'll need a second DVD soon [if just for a few MB!] :P

henriette

@ NightOwl


Quote:

the last xxx.cda (I can't remember--is that the correct Ghost .3 after the file name for optical files?) as can be verified by looking at the time/date stamp for the file.  (Also, if you load an image file that's saved to optical disc using Ghost Explorer, you are asked to insert the first disc, and then the last disc so Ghost can read the first .gho file and then the last file on the last disc for the end of procedure information.)

1. I am not asked to insert a disc!
2. I opened Ghost Explorer > inserted the disk (DVD) > find in folder (optical drive) listed:
CDR00001.GHO
CDR00002.GHO
CDR00003.GHO
CDR00004.GHO

> Only CDR0001.GHO can be opened. Preferences: "Does NOT contain bootpartition" ( = boot.exe missing ??).
When trying to open any of the others (2,3,4):
"No Ghost file!"

What's wrong/did I get you wrong :-?

henriette

@ henriette


Quote:

Will Ghost definitely ask me for a second DVD if necessary

Yes!


Quote:

1. No Ghost explorer possible anymore, when more than 1 DVD.

Ghost Explorer works fine with multiple CD's or DVD's!  You point Ghost Explorer to the first image file on the first optical disc, and then insert the last optical disc and point Ghost Explorer to the last file of the image set.  You might have to swap discs multiple times after that--Ghost Explorer tells you which disc to insert when needed.  If you have two optical drives, you can put the first disc in one drive and the last disc in the other drive.  Ghost Explorer will then switch back and forth between the two without swapping discs--until it asks for the third, forth, etc. disc.


Quote:

2. Will restore from two DVDs work without problems ???

Not a problem!  Just feed Ghost discs when asked for them.


Quote:

So the reason for the calculating problems of Ghost 2003 is the fact that I'll need a second DVD soon [if just for a few MB!]

If you're asking about the *-14 MB* correction--No, that has nothing to do with Ghost's estimation that 2 discs will be *needed* for the backup image size.  The 2 disc estimate is based on Ghost's built-in *gestimate* of how much your files can be compressed--and until Ghost has actually gone through the process--it doesn't know for sure *exactly* how compressible your files will be.

I have no idea exactly what the *-14 MB* correction* is all about.  Perhaps Ghost was saving that space for *bookkeeping* chores--and when the final file was compressed, Ghost determined it did not need those extra MB's for this particular backup.


NightOwl wrote on Jun 2^nd, 2012 at 12:53pm:

if you load an image file that's saved to optical disc using Ghost Explorer, you are asked to insert the first disc, and then the last disc so Ghost can read the first .gho file and then the last file on the last disc for the end of procedure information.

Quote:

1. I am not asked to insert a disc!

I said that poorly!  You insert the first disc and point to the first file of the image backup set--the CDR00001.GHO.  Then, Ghost Explorer will pop up a dialog box asking you to navigate to the last file of the image set--if on multiple discs you have to remove the first disc, and insert the last disc, and then if needed, click on the optical drive letter to make it list the files on that disc.  Then you select the last file in that list.  If you have two optical drives, you can leave the first disc in the first drive, and tell Ghost Explorer in that dialog box to switch to the other optical drive that should have the last disc inserted, and then you can choose that last file on that last disc.


Quote:

When trying to open any of the others (2,3,4): "No Ghost file!" What's wrong/did I get you wrong

Only that first Ghost file can be opened using Ghost Explorer.  I'm not positive, but if all the image files fit on a single disc, then you might not have to point Ghost Explorer to the last file on that same disc--Ghost might *automatically* find it--but, maybe not.  If not, then when the dialog box pops up you just tell Ghost Explorer which file is the last file of the image set.

You will not be able to *open* any of the other files that are part of the entire backup set--only the first one--same thing happens for an image set on a HDD--you can only open the image set by pointing to the first file of the set.


NightOwl wrote on Jun 2^nd, 2012 at 12:53pm:

xxx.cda (I can't remember--is that the correct Ghost .3 after the file name for optical files?)

Okay, so your response reminded of the correct answer:


Quote:

CDR00001.GHO CDR00002.GHO CDR00003.GHO CDR00004.GHO

All the files on an optical disc have the *.gho* extension.  And the files are named with the *CDRxxxxx* file name--where xxxxx is the number of the file in the image set.

@ NightOwl

All questions answered & explained excellently!
Thank you SO much 

henriette  :-* (old lady's kissy)

NightOwl wrote:

"you can assume that you are nearing the limit of what will fit on one DVD"

henriette wrote:

"That's exactly why I posted, and what I was afraid of... just for a few MBs  ::)

I checked & checked ... can't delete/uninstall progs (needed!). Got CCleaner + TuneUpUtilities ++ to keep my PC as clean as possible."

Since you're working with XP, chances are you have a ton of backup folders that came from Windows updates.  In systems I cleanup for others, it's not unusual to see 5-10 years of backup folders! Except for the most recent ones, you're never going to uninstall those updates, so you could potentially shrink an installation by a few hundred MBs by deleting backup folders more than a few months old.

See Windows XP Update Remover for details.  Just be careful to click the [Remove backup folder] button and not the [Uninstall update] button!

@ Dan Goodell


Quote:

chances are you have a ton of backup folders that came from Windows updates

Well, I DO manually delete the '$NTUNINSTALLKBxxxxxx$' + the *.logs thereof.

CCleaner and/or TuneupUtilities will remove the registry keys (KBs - from other registry hive, I assume) thereafter.
BUT: that way the KBs remain definitely in the registry, which is important to me > e.g. I look *regedit* if I have a certain KB installed already.
However, that procedure might leave a lot of crap in the registry  :-/ ... I may have done the wrong *thing* for years!


Quote:

See Windows XP Update Remover for details.  Just be careful to click the [Remove backup folder] button and not the [Uninstall update] button!

I could not tell what the above tool does - regarding the KBs in the registry! ... and I'm not the one to install a tool without knowing what it does exactly.

Would you be as kind as to tell me ? Or, better, will the KBs definitely remain in the registry after having used that tool ?

If so, I'd be very interested in trying. Thanks a lot :=)

henriette  :)

henriette wrote on Jun 7^th, 2012 at 8:14am:

Well, I DO manually delete the '$NTUNINSTALLKBxxxxxx$' + the *.logs thereof.

Okay, then you've already pruned the bloat.  Those $NTUNINSTALLKB...$ files are where I was thinking you might be able to shed some MBs.

In the past, I used to do it manually like you're doing, but nowadays find it faster and less error-prone to accomplish the task with WUremover.




Quote:

CCleaner and/or TuneupUtilities will remove the registry keys (KBs - from other registry hive, I assume) thereafter. [...snipped...] I could not tell what [WUremover] does - regarding the KBs in the registry! ... and I'm not the one to install a tool without knowing what it does exactly.

Are you talking about the [HKLM\Software\Microsoft\Windows\Updates] key?  I think those are supposed to be there.  I assume that's the list Windows Update checks to see what updates are installed.

We're not talking about uninstalling updates, just removing the backup folders to save space.  Therefore I can't imagine why there should be any registry entries that need to be cleaned up.

At any rate, I've got 319 KB keys in my [...\Updates] registry branch, and CCleaner doesn't offer to clean out any of them.  (FWIW, those 319 keys only account for about 200KB of the size of my registry hive, anyway.)

@ Dan Goodell


Quote:

Windows XP Update Remover

Good one--I like the looks of that utility!

In the past, I used Doug Knox's :  XP Remove Hotfix Backups.exe


Quote:

Removes Hotfix Backup files and the Add/Remove Programs Registry entries.

The *free* version was an all or nothing utility--you could not remove selected Backups.  But, I see that the *licenced* version, which did allow for selective removal, is not available at this time  ( I am temporarily suspending sales of licenses for this product, due to changes made by Microsoft. )

But, he does not explain what changes by Microsoft made him decide to stop the licensed version.

I haven't been using the free version recently because I have a new system with a large HDD, and space has not been a problem--and I'm not trying to fit the WinXP partition on a single DVD!

@ henriette


Quote:

I could not tell what the above tool does - regarding the KBs in the registry! ... and I'm not the one to install a tool without knowing what it does exactly.

Does this help:  How To: Remove $NtUninstall folders


Quote:

Solution You can either remove the folders and their corresponding Registry entries manually, or use a removal utility. The manual method is tedious, but described so that you can understand what the automated utility is doing.

@ Dan Goodell & NightOwl

I have to admit, I did not do a *clean* job by deleting manually - as described in http://www.tech-pro.net/how-to-remove-ntuninstall-folders.html

So I will use the "Windows XP Update Remover* from now on.

Question #1:
Will that tool possibly clean leftovers from the registry (which I did not delete)  :-?

Question #2:
I have never touched the IE7 + IE8 updates [just the updates of both add to 534MB!]. Would you recommend me to delete those as well ?
(thought they might be needed in case of XP-repair or whatever).
Since I restore images instead, I might not need those updates, anymore  :-?

Thank you both for your excellent support!

henriette  :)

henriette wrote on Jun 9^th, 2012 at 7:17am:

So I will use the "Windows XP Update Remover* from now on. Will that tool possibly clean leftovers from the registry (which I did not delete)

I don't know, and I don't have a system with that condition to test.

Earlier, you said, "CCleaner and/or TuneupUtilities will remove the registry keys (KBs - from other registry hive, I assume) thereafter."

I'm still not clear what that refers to. Perhaps I haven't seen that feature merely because I haven't had systems with orphaned KB registry entries, I don't know.  Maybe if I had, one of those utilities might have offered to clean them up.

You seem to be more familiar with what those utilities are doing in this case--has it been your experience that they were cleaning the orphaned registry keys after you manually deleted the backup folder?  If so, then maybe you don't have any orphaned keys left.




Quote:

I have never touched the IE7 + IE8 updates [just the updates of both add to 534MB!]. Would you recommend me to delete those as well ? (thought they might be needed in case of XP-repair or whatever). Since I restore images instead, I might not need those updates, anymore

That's exactly my rationale, so I delete those backup folders, as well.

Once you have a stable, working Windows installation, you can delete all backups except for the last couple months, then image it.  I might leave the last month or two just in case there's some problem with a recent update that you haven't noticed yet.  That leaves you the chance to still uninstall it if you needed to.

But I would never, ever, uninstall a very old update after months of subsequent updates have been applied.  You just never know how intertwined they may be, and if there are a lot of subsequent updates it seems to me that increases the odds that uninstalling an old update might break something else.  That's the kind of situation in which I'd roll back to a prior image instead.

In case it helps, let me describe my long-term imaging strategy.

Let's assume a starting point of some pristine, stable OS installation.  It may be a brand new computer, or a used computer restored to factory state, or a clean install from CD/DVD--that doesn't matter.   The point is I have a known good, stable, virus-free installation that hasn't been sullied by daily use yet.  I make an image and set it aside for a year.

After a year my OS has been pounded by daily use, new programs have been installed, some programs have been uninstalled, some programs have installed unwanted bundleware I've had to remove, there have been hundreds of Windows updates, some of those updates have subsequently been superceded by other updates, and there have been countless registry additions/changes/deletions.  Who knows, maybe even some malware snuck by a some point and damaged some dll or left some detritus before my AV program killed it.  In effect, it's like a used car that's picked up dings and dents along the way.

At the end of the year, I first make a note of what new programs were installed over the year that I've kept, then I restore the OS from my pristine, year-old backup image.  I delete all the old WU backup folders (on the principle they've proven over the year that they're keepers).  Then I re-add the new programs that were keepers, and let Windows apply the intervening year's update patches.  (Note this neatly avoids most of the "oops" patches that Microsoft subsequently repatched.)  Then I reimage this updated, pristine installation, and set it aside for another year.

A year later, the process is repeated.  This practically guarantees that each year I am starting with a known-good, virus-free, corruption-free, pristine OS, with no excess cruft or detritus from daily use.  It's basically the same as doing a clean install once a year.  I've got a system that's as lean and fast as it could possibly be.  (I've got an 8-yr old desktop and a 5-yr old laptop that still boot in well under a minute and run faster than most users' more modern machines.)

I'll still make interim backup images at significant breakpoints throughout the year (like before installing some major program or applying a SP update), but those are images just in case of emergency.  I may never need them.  In contrast, the yearly pristine images definitely get used at the end of a year.

Dan, I understand what you mean. And it's a good point you make [smiley=thumbup.gif]

The idea of a *pristine* image in my case, though, is most unlikely (don't think I have such an image) - couldn't tell  :D
I have ~ 70 images from the very beginning of XP install to yesterday. Hard/software have changed that much & often, it would take *forever* to get all that up-to-date.

note: I write daily records of each step. So I might have to struggle through several hundred pages, still having doubts whether "this is it" or not ... not even "this may be it" ::)

If I had gotten your advice years ago, I would have handled it different = the way you do it. Too late now.

However, I probably will have to get used to restoring earlier images - after 2014 = end of XP.
I intend to stick with XP. My hardware is not win 7-ready in the least!
Old board, CPU, +++, and = still EIDE/PATA.

Addition: Yesterday I used *windows xp update remover*.
Only "IE7-updates" (+ 1 latest KB which I didn't touch) were shown. Not so "IE8" - I guess it's because I have IE8 in use.

Thanks for your great support.

henriette  :-*

 

henriette wrote on Jun 11^th, 2012 at 5:53am:

If I had gotten your advice years ago, I would have handled it different = the way you do it. Too late now. However, I probably will have to get used to restoring earlier images - after 2014 = end of XP. I intend to stick with XP.

If it were me, I think I'd probably bite the bullet and start over from a clean install.  Yes, it will be painful, but since you're adamant about keeping it for the long haul, it might make sense.

Most people would look at such a system and say, "Yeah, maybe it could be cleaner, but it works okay and I don't want to reinstall and start over, so I'll live with it."  But when it eventually becomes unbearable they can fall back on just buying a new computer.  They won't be able to get XP and may not like Win7 (or Win8), but they'll accept that as the tradeoff for avoiding a clean install/startover.

You already can't get XP, and in another year you won't be able to get Win7, either.  So if you're adamant about sticking with XP, starting over with a new computer will be out of the question.  In your case it's not really a question of when Microsoft's official support ends, you want to keep your XP running smoothly for as long as possible, whether Microsoft's supporting it or not.

@ Dan Goodell


Dan Goodell wrote on Jun 9^th, 2012 at 5:37pm:

Let's assume a starting point of some pristine, stable OS installation.It may be a brand new computer, or a used computer restored to factory state, or a clean install from CD/DVD--that doesn't matter. The point is I have a known good, stable, virus-free installation that hasn't been sullied by daily use yet.I make an image and set it aside for a year. At the end of the year, I first make a note of what new programs were installed over the year that I've kept, then I restore the OS from my pristine, year-old backup image.  I delete all the old WU backup folders (on the principle they've proven over the year that they're keepers).  Then I re-add the new programs that were keepers, and let Windows apply the intervening year's update patches.  (Note this neatly avoids most of the "oops" patches that Microsoft subsequently repatched.)  Then I reimage this updated, pristine installation, and set it aside for another year.

Interesting *imaging strategy*--but, unless I'm missing something, as the years go by you will be gradually adding more and more programs--some of which may cause slight system slowdowns that you are not really aware of at the time--you just know you want to continue to use them.  So those programs build up year after year in your yearly *pristine installation*.  And the gradual additive effect on system performance could slow things down eventually.  Seems like this method just *delays* the process by one year because you only go back one year each time.  (Yes, I understand that you have *cleaned* out the detritus left behind by the various installs and uninstalls--but, you're not really going back to a *pristine* state--just last years state with all the software you had at that time.  Seems like you are still gradually *bloating*.

Don't get me wrong--not *criticizing* the method--I just find it hard to find time to analyze what programs I have installed during the last year and I want to keep, and when I restore back one year, I now have to reinstall all those programs that I didn't keep track of all that well to begin with.

I do regular image backups and special backups before any major program installations or updates or upgrades.  If the system goes down from one of those, I revert to the most recent known good, stable system, and try again or move on.  (Crossing my fingers)--It has worked well so far--and hope it continues in the future  :) !

@ henriette


henriette wrote on Jun 11^th, 2012 at 5:53am:

The idea of a *pristine* image in my case, though, is most unlikely (don't think I have such an image) - couldn't tell

Well, it may not be *pristine*, but you could consider your current system state (assuming it's stable and running smoothly) to be this year's *pristine* starting point, and then go forward with what Dan is suggesting.

But, with WinXP support going away in Aug, 2014, I suspect all the Windows Updates for WinXP will end then too.  I don't know that you would want to restore *last years* backup--because you will loose all the updates between your last years backup and the end date of Windows Update for WinXP.  So if those Updates are no longer available, you loose them.  So make a final *pristine* image that includes those updates through the end date of support for WinXP!

NightOwl wrote on Jun 12^th, 2012 at 2:23pm:

So those programs build up year after year in your yearly *pristine installation*. And the gradual additive effect on system performance could slow things down eventually. Seems like this method just *delays* the process by one year because you only go back one year each time. (Yes, I understand that you have *cleaned* out the detritus left behind by the various installs and uninstalls--but, you're not really going back to a *pristine* state--just last years state with all the software you had at that time. Seems like you are still gradually *bloating*.

No, my strategy is indeed almost as pristine as doing a genuine clean install every year.  If I do a clean install and image it, then add programs A & B and reimage, and then add programs C & D and reimage ... how is the result much different from doing a clean install and adding programs A, B, C & D all at once?

BTW, nothing is ever uninstalled from the pristine image.  Programs A, B, C & D are in the image because I've already determined they're keepers.  If I did a clean install every year, they'd still be included in the reinstall.

To be clear, only programs I'm sure about are added to the pristine image.  Let's say that during the intervening year I've installed programs #1-2-3-4-5-6, uninstalled #2 and decided I don't really use #3 & 6: then I would only add #1-4-5 to the pristine image ... just like my system would be if I did a complete reinstall of everything from scratch.

Programs that I've only recently installed (say, the last 2 months) are never included because it takes me longer than 2 months to decide if a program is really a keeper.  So let's say there's also programs #7-8 that were recently installed:  I'll restore from last year's pristine image, add programs #1-4-5, reimage to update my pristine image, then add programs #7-8 and put the rebuild into service.  A year from now I'll know whether #7-8 are candidates for next year's pristine update.

The most likely exception to the "nothing uninstalled" rule is probably going to be printer drivers.  They may be keepers for several years and then be rendered surplus when you buy a new printer.  In that case, I'll uninstall when updating the pristine image.  (I change printers so seldom, though, that this may only happen once or twice during the lifetime of a pristine image.)

My method isn't completely identical to a yearly clean install, though, because there may be program updates.  For example, let's say my pristine image has version 4 of some hypothetical program, and during the year my in-service system was gradually upgraded to versions 5-6-7-8.  (That's bad for bloat.)  My strategy would have the program jump from ver.4 to ver.8 (that's better) when pristine is reimaged, whereas a genuine clean install would start straight from ver.8 at the outset (that's best).

Nevertheless, the impact on bloat is extremely minor and practically inconsequential.  Sure, there's bloat because of the hundreds of Windows updates, but you'll have that with a clean install, too, so that doesn't count.  What we're looking at is the difference between my strategy vs. a genuine clean install.

Remember, it's not like a daily use system which gradually bloats through 365 days of constant use and updates.  There's one day of updates  *per year*.  If the lifetime of your system is 10 years, that's like subjecting your system to updates only 10 times, as compared to 3,650 times for a system in constant daily use.

To me, the minimal bloat is more than worth it, particularly if the alternative--a genuine clean install once a year--is so daunting that it doesn't get done.  When he started this website, Rad wrote that the best imaging app is the one you'll actually use.  Likewise, a genuine clean install is of no benefit if it doesn't get done.

NightOwl wrote on Jun 12^th, 2012 at 2:35pm:

with WinXP support going away in Aug, 2014, I suspect all the Windows Updates for WinXP will end then too.  [...]  So make a final *pristine* image that includes those updates through the end date of support for WinXP!

I could be wrong, but I don't think they're yanking the ability to update a XP reinstall.  I think it just means MS won't be putting out any *new* updates after that date.  If you reinstall XP SP3, I think you'll still be able to update it with any updates released prior to Aug 2014.

For instance, MS has already ended support for XP SP2 in Jul 2010.  (The Aug 2014 date is for XP SP3.)  Yet, I can restore an old SP2 image and if there are any updates prior to Jul 2010 that haven't been installed, it will notify me, "Updates are available," and will install them.

Nevertheless, what you say is good advice and recommended practice.

Hiya  :)

Dan Godell wrote:

Quote:

I don't think they're yanking the ability to update a XP reinstall.  I think it just means MS won't be putting out any *new* updates after that date.  If you reinstall XP SP3, I think you'll still be able to update it with any updates released prior to Aug 2014.

I was told the same.

Apart from that, there are *offline update packs* available (German/English language - scroll down a bit for English):
http://www.wsusoffline.net/

... + other links in German language only.
That should be the least problem  ;)

My present XP is running fine.

XP3 came already with my XP-installing-CD.
Not so e.g. IE8 etc.!
One of the many reasons why I wouldn't want to restore images from ages ago  ::)

I'll stick with _my_ imaging method, as long as there's no major problem.

The only thing that scares me is catching an MBR-virus.  :o
IMHO there wouldn't be any other way to get rid of it than doing a fresh XP install. Perhaps I will not see that day.

note: *repair console* (or what you call it) doesn't work on my PC, the option was not available when trying it once [file missing or something ...]. Maybe one has to install the *repair console*.

Be it as it may, I'm getting old & bold ... hoping for the best  ;D

henriette  :)

@ henriette


Quote:

The only thing that scares me is catching an MBR-virus.    IMHO there wouldn't be any other way to get rid of it than doing a fresh XP install.

Actually, having Ghost backup images can *save the day*!  You have to use a utility in DOS that can *zero* the MBR.  A simple re-format does not automatically create a new MBR that would wipe out a MBR virus.

If you are doing *whole disk* images, then Ghost 2003 will put the MBR that was present when you made that particular image--so it would have to be an image that was pre-MBR virus infection.  This only occurs if an existing HDD has had the MBR wiped clean--which means the virus is gone too.

If you are doing only *partition* images, it's a little more complicated--because restoring a partition image to a partition requires that there be a partition already there as a destination.  You can, however, tell Ghost 2003 to do a *Partition-to-Disk* (that's *whole disk*).  Now Ghost will restore that partition to a HDD that has no partition--and the MBR from when that image was taken will also be restored.  Again the HDD has to have a *zeroed* MBR.  And, I can't remember for sure--but, I think you will get the opportunity to specify how much of the destination HDD should be used.  So, if the OS image comes from a source HDD that had multiple partitions, you would restore the OS partition using *Partition-to-Disk*, and then create the other partitions later.

So, the key, is *zeroing* the MBR before the restore of the image!


Quote:

note: *repair console* (or what you call it) doesn't work on my PC, the option was not available when trying it once [file missing or something ...]. Maybe one has to install the *repair console*.

You can install the *Recovery Console* on your HDD--but, it will take up a bit of room--maybe push you over to that second DVD when backing up.  You can also use the WinXP installation disc to boot from, and from there elect to load the *Recovery Console* from the CD.  And, the Recovery Console, with the correct command, can replace the viral infected MBR with a new MBR from the Console.  That process too solves the MBR viral problem!

Here's a Google search with relevant links:  installing WinXP recovery console

henriette wrote on Jun 13^th, 2012 at 4:26am:

The only thing that scares me is catching an MBR-virus.  IMHO there wouldn't be any other way to get rid of it than doing a fresh XP install.

Not true.  A full-disk image can easily restore everything, but even with separate partition images you can completely wipe the HDD so nothing's on it, create fresh empty partitions, then restore each partition from its image.  You'll have to go on memory to determine your partition sizes, but it doesn't have to be exact so that's usually not important to people.

NightOwl discusses whether the MBR bootstrap code gets restored, but understand the bootstrap code is nothing special.  Many partitioning utilities may add generic or common bootstrap code if they see the HDD doesn't already have it.  Even if they don't, it's easy to recreate.

There are two kinds of MBR or boot sector viruses.  The more sinister kind actually moves your partition table to its own location and zeroes the original, so if you boot through the virus your partitions are all there, but if you remove the virus your partitions appear to be gone, too.  (They actually aren't, but most users don't know that and end up reformatting, thereby killing the hidden partitions themselves.)

If you want to protect yourself, either make a whole-disk image, or if you use partition images then backup the MBR separately.  Terabyte's freebie, MbrWork, is great for that.  Use it to backup Track 0.  If/when the time comes, a full disk restore can be accomplished by using MbrWork to restore Track 0 (which will restore your virus-free MBR and partition table), and then restoring the contents of each partition from your images.

:-? :-? :-?

NightOwl wrote:

Quote:

the key, is *zeroing* the MBR before the restore of the image!

How to do that  :-[hr]

NightOwl wrote:

Quote:

You can also use the WinXP installation disc to boot from, and from there elect to load the *Recovery Console* from the CD.  And, the Recovery Console, with the correct command, can replace the viral infected MBR with a new MBR from the Console.  That process too solves the MBR viral problem!

As I said, I tried that once. I think it didn't work because I was asked to insert a floppy, which I don't think I have.
Is that possible  :-? > XP CD = XP SP3 professional.

Whatsoever - I don't want to install/use the *recovery Console*. Seems too complicated.

---

FYI: I create images of C:\ only,,, to my 2nd internal HDD | 1st partition. lack of space!!!, since Ghost 2003 won't recognize my 1.5TB external HDD = too big].

Just once I created a *whole-drive-image* (just enough space on HDD 2), when I had to replace my HDD ~ 1 year ago, then I restored the image to the brandnew HDD. Thanks to NightOwl's  :-* detailed instructions it worked excellently   [smiley=thumbsup.gif]

I do intend to create another *whole-drive-image* to HDD 2 (internal | 1st partition). Just thought I'd wait for another while. > Both internal HDDs had been replaced by brandnew ones about 1 year ago.

Dan Godell wrote:

Quote:

if you use partition images then backup the MBR separately.   Terabyte's freebie, MbrWork, is great for that.  Use it to backup Track 0.  If/when the time comes, a full disk restore can be accomplished by using MbrWork to restore Track 0 (which will restore your virus-free MBR and partition table), and then restoring the contents of each partition from your images.

:-? ---> Why couldn't I _if I knew how to accomplish that *zeroing MBR*_:
1. restore an image of C:/ (= Ghost image)
2. Copy back the data onto the other partitions (I *create* regular up-to-date backups of each partition!) - no Ghost images, though.

Please understand that I have to read your posts over & over again to *get* what I'm supposed to do at all ...
...  :-/ ... how do I *zero* the MBR --- where is "it situated" and so far ...

> I will do a search for MBR in German, maybe I'll understand  :P

henriette <confused>

I read WIKI + found an article that UBCD (Ultimate Boot CD)
http://www.ultimatebootcd.com/

should do the trick.

Users say in forums: "bootrec /fixmbr".

Just what tool should I use ?

questions:
Would that also work if I had a virus ? I mean, would I get rid of a boot virus by using just that ?
I presume that the HDD (partly, at least) would be wiped.

What & how to do before & after  :-? ... Wow, it's getting most weird  :D

Prerequisite is that my PC is booting, of course.

note: I've used UBCD for years, checked HDDs + RAM.

henriette  :)

Some Definitions:

The MBR ("Master Boot Record") is in the first sector (LBA 0) of the first track (Track 0) of your HDD.  This sector contains your partition table, a randomized DiskID (to differentiate disks), and bootstrap code.  In some contexts, "MBR" refers to just the bootstrap code, while in others it is used to refer to the entire first sector--all three parts.  (Less commonly, some references may also refer to the MBR as being the entire first track.)  The lesson here is don't take the term too literally when reading various articles because you may not be sure what, exactly, they're referring to.

Track 0 is not part of any partition--hence, why it is not typically captured in a partition image.  Think of it like a book with chapters and a table of contents.  Your partitions are the "chapters" and Track 0 contains your TOC.  If you photocopy just one chapter from a book, you don't usually also copy the TOC.

A whole-disk image will capture all parts.  Alternatively, you can achieve the same result with individual images of each partition plus a Track 0 backup.

It's okay that you're not imaging your data partition--I don't, either.  Like you, my data is backed up by copying, not imaging.  Only the OS partition requires imaging.  So the equivalent of a whole-disk image would be a Track 0 backup, an image of the OS partition, and duplicates of all your data files.


Viruses and the Boot Process:

When your computer boots, the BIOS does its thing and then turns control over to the first sector, LBA 0, on the HDD.  You computer would hang at that point if there's no bootstrap code there.  The bootstrap code's job is to continue the boot process by determining which partition in the partition table control should be transferred to.

A boot sector virus (aka, MBR virus) is one that replaces the LBA 0 bootstrap code with itself.  The more sophisticated/sinister viruses will also move the partition table.  So, if you boot through such a virus the process goes BIOS > infected LBA-0 > alternate partition table > OS partition.  Everything appears to be there, infection notwithstanding.

If you subsequently replace the bootstrap code to remove the virus, the boot process now goes BIOS > LBA-0 > real partition table > hang.  If the real partition table hasn't also been repaired, the repaired bootstrap code will think your hard disk has no partitions.  Understand, however, that the virus only tinkered with your "table of contents" here, not your "chapters".  If the TOC says there are no chapters, the bootstrap code isn't sophisticated enough to figure out they may actually still be there.  As I mentioned, this is where many users go wrong.  Instead of repairing the partition table, they think the virus deleted their partitions so they reformat and start over, thereby destroying the partitions themselves instead of recovering them.


Repairing the MBR:

When NightOwl referred to zeroing the MBR, that was strictly in the context of inducing Ghost to restore the MBR bootstrap code (if it had saved it).  I think he was saying that Ghost doesn't restore bootstrap code if it sees something there already, so zeroing the MBR is meant to trick Ghost into restoring the copy (if it made it) of your bootstrap code.  However, use MBR-clearing tools with caution.  Most tools that clear the MBR will also clear the partition table, so only use them if you have other means of repairing or restoring your partition table.

If you're going to be restoring your bootstrap code by other means, you don't need to zero the MBR.  All you need to do is overwrite whatever is there, zeroes or not.

The "bootrec /fixmbr" command is Microsoft's command to replace the MBR bootstrap code with known good code.  It does not alter the other parts of LBA 0 or Track 0, such as the DiskID or partition table.  That will get rid of the virus, and you don't have to zero the MBR first.  However, that alone won't be enough if the virus was sophisticated enough to move your partition table.

FYI, note that "bootrec /fixmbr" is not concerned with restoring the exact bootstrap code you had before, it simply says, "We don't know what you had before, but we know this code works so that's what we're using."  (That's what I meant when I earlier said the bootstrap code wasn't anything special.)

In contrast, MbrWork backs up and restores what you actually had.  It not only backs up all of LBA 0 (the bootstrap code, the DiskID, and the partition table), but goes further and backs up all of Track 0.  When you restore Track 0, you end up restoring all three parts of LBA 0, so even if the virus had moved your partition table it won't matter because MbrWork is restoring your saved partition table, too.

There are similar tools that can backup and restore LBA 0, and will work as well.  What I like about MbrWork is it backs up more than just the first sector.  If you've installed a multiboot manager, for instance, it not only replaces your generic bootstrap code with the multiboot manager, it typically needs to put extra code in other sectors of Track 0.  Backing up only LBA 0 may not be enough to backup your multiboot manager, so if you should need to restore from that backup you'd probably need to also reinstall the multiboot manager.  Backing up all of Track 0 may be able to ameliorate that.

It's not always necessary to backup more than LBA 0, but I don't bother trying to figure out whether I need to or not.  The backups are tiny, so I backup all of Track 0 as a matter of routine.

WOW, Dan  :)

How can I ever thank you for spending so much time  :-*

UBCD contains *MbrWork* (Boot Management).

http://www.ultimatebootcd.com/

(scroll down to see the content).


Quote:

MbrWork backs up and restores what you actually had.  It not only backs up all of LBA 0 (the bootstrap code, the DiskID, and the partition table), but goes further and backs up all of Track 0.  When you restore Track 0, you end up restoring all three parts of LBA 0, so even if the virus had moved your partition table it won't matter because MbrWork is restoring your saved partition table, too.

I take from your post that *MbrWork* is a brilliant tool for me  :)


Quote:

If you've installed a multiboot manager

My PC has single boot only (shown while booting). --> old board &&.

My main internal HDD = HDD1 has 5 partitions > C-D-E-F-G.

It's a WD HDD, 500GB < = biggest recommended size for internal HDD ---> support ASUS.


Quote:

It's not always necessary to backup more than LBA 0, but I don't bother trying to figure out whether I need to or not.  The backups are tiny, so I backup all of Track 0 as a matter of routine.

I'd assume the above goes for "multiboot" only. So I wouldn't need it ...

Still there are a lot of questions: (so sorry ...   :-/

1. What commands do I need °within° *MbrWork* (whole procedure) ?

2. Where should I store the backup of *MbrWork* ? --> HDD2 internal ?


Quote:

you can achieve the same result with individual images of each partition plus a Track 0 backup.

Do you mean by that (having an image of C:\ only):

> Restoring image of C:\ , THEN add the *MbrWork* backup to C:\ ?

3. At what point exactly "restore" the *MbrWork*-backup ?

4. Do I (mainly) have to use *MbrWork* only when I have caught a MBR-virus ?

5. how can I tell If I've caught a MBR virus ?

---

note #1: I'm using *ESET NOD32 AV 5*.

note #2: I've searched the web + UBCD forums > can't seem to find any instruction of how to use *MbrWork*.
Neither in English nor _of course  ::)_ in German.

You may understand that it's fatal if I'm already in PC-DOS > *MbrWork*, not knowing what to do next!

Thanks again for your detailed help - I'm hoping the board will forgive me for asking non-backup-software questions in here :-[

henriette   

@ henriette


Quote:

UBCD contains *MbrWork* (Boot Management).

Yes, it appears to be the same version you can get from TeraByte Unlimited Freeware page.  Scroll down to about the middle of the page and you will find *MBRWork* version 1.08.


Quote:

1. What commands do I need °within° *MbrWork* (whole procedure) ?

Quoting from the above TeraByte page:


Quote:

MBRWork is a utility to perform some common and uncommon tasks to the MBR/EMBR sectors of a hard drive. It should only be used by power users who understand how computers work. The readme.txt file in the ZIP contains a list of the tasks available.

So, probably the various tasks and how to use them are in that *readme.txt* file.  Just extract the files from the ZIP and then you can load it using NotePad or WordPad.  Most likely that *readme.txt* file is also on the UBCD disk in the directory where the MBRWork *.exe* file is located.


Quote:

2. Where should I store the backup of *MbrWork* ? --> HDD2 internal ?

Floppy disk or any other HDD that you will have access to if you need to restore it to the source HDD from which it came.


Quote:

3. At what point exactly "restore" the *MbrWork*-backup ?

When you have decided to replace the MBR (for whatever reason) with that backup MBR file--and before you restore the Ghost OS partition file.  If you do any HDD changes to the basic structure--like any changing of the partition sizes, number of partitions, etc.--you need to make an updated backup of the MBR--have to keep it up to date.  If you don't make any changes, ever, then that original backup will remain valid.


Quote:

4. Do I (mainly) have to use *MbrWork* only when I have caught a MBR-virus ?

Probably, unless some other event somehow corrupts your MBR.


Quote:

5. how can I tell If I've caught a MBR virus ?

When you suddenly have unexplained behavior that appears to be *bad*, and you have not installed a program that you know is supposed to be doing that behavior.  Even then, it will probably be hard to know for sure--you will have to rule out other possibilities, probably ask for help, or Google the behavior to see if others recognize it as a problem.  Possibly running multiple scans using your Antivirus program, or using the on-line scans provided by various Antivirus providers--sometimes you have to run an antivirus scan after you close down Windows and run it from a booted optical disc.


Quote:

I'm hoping the board will forgive me for asking non-backup-software questions in here

Not to worry!  Backing up the MBR is part of what imaging backups of the OS include--either inside of the imaging program--or separately like MBRWork.


henriette wrote on Jun 14^th, 2012 at 10:38am:

NightOwl wrote: Quote: Quote: the key, is *zeroing* the MBR before the restore of the image! How to do that

Any disk editor program that you can use once booted to DOS will work.  Just below the MBRWork v1.08 download mentioned above on TeraBytes Free Utilities is another MBR program called *MBR Utility*.   Quoting its description:


Quote:

MBR allows you to manipulate a drive's master boot record (MBR) via the command line. For example, MBR is capable of deleting all the partitions in a MBR, zeroing out a MBR, installing a standard MBR, and more. MBR runs under DOS/Linux/Windows

And, there are other tools and utilities that can do this for you.  I suspect that the MBRWork program also has this function--but, I have not checked yet.

This is a screenshot from an older MBRWork version but it outlines the menu. The newer version has a few extra choices.

http://members.shaw.ca/LeesPlace/mbrwork.htm

To backup the First Track you must be running MBRWork from writable media. If you run it from a USB flash drive you must remember that the flash drive is HD0 so you have to change to HD1 before you "Backup First Track". From a floppy, your first internal HD will be HD0.

Brian and NightOwl have covered a lot of the specifics, but I'll elaborate on a few points.



henriette wrote on Jun 15^th, 2012 at 7:35am:

I take from your post that *MbrWork* is a brilliant tool for me [...] re: "It's not always necessary to backup more than LBA 0, but I don't bother trying to figure out whether I need to or not.The backups are tiny, so I backup all of Track 0 as a matter of routine." I'd assume the above goes for "multiboot" only. So I wouldn't need it ...

In general, yeah--but it's not always obvious when you might have a de facto "multiboot" system.

For instance, during the XP-era many OEM computers (Dell, HP, and maybe others) came with a proprietary dual-boot configuration to implement their "factory restore" options.  They appeared to be single-boot systems because the user didn't see a boot menu, but in fact there was a hidden, alternate-boot function accessed via magic key combinations at boot time.

Some third-party vendors may implement similar techniques.  Acronis, for example, touts their "Secure Zone" feature, but if you install it you are essentially installing an Acronis-specific dual-boot, accessible via magic keys.

If you install a linux-only machine, the grub bootloader is larger than a single sector, so uses some of those additional sectors in Track 0, as well.

My point is there is no harm in backing up all of Track 0 instead of just LBA 0 alone.  At worst, a Track 0 backup is capturing LBA 0 plus a bunch of empty sectors--but there's nothing wrong with that.  However, if one of those erstwhile "empty" sectors actually isn't empty and contains crucial data in it, a Track 0 backup can save your rear.

Rather than trying to figure out when or if you need to backup more than LBA 0, just do a Track 0 backup as a matter of habit and you'll never have to worry about it.




Quote:

Do I (mainly) have to use *MbrWork* only when I have caught a MBR-virus ?

Like a partition image, you only need to use it if you think something's wrong, or if you're moving everything to a new HDD.  You're only going to restore a partition image if you think something's wrong with your existing partition.  You're only going to restore Track 0 if you think something messed up your bootstrap code or your partition table.

If you're only needing Ghost to restore your OS, you don't need to restore everything on your hard disk.  You don't need to also restore Track 0 unless you suspect there's something wrong with it.

As NightOwl cautioned, be careful if you've subsequently repartitioned your hard disk.  Repartitioning changes your partition table, so you don't want to restore Track 0 and paste your old, obsolete partition table back in there.  If you repartition, make a new Track 0 backup.

If you ever need to rebuild your entire HDD from scratch--say, on a new, replacement HDD, for example--you need to restore your MBR, partition table, and all partitions.  There are three common strategies for backing up all of those pieces:

(1) A Track 0 backup, plus a Ghost image of C, plus duplicate copies of the contents in the other four partitions.  (The non-OS partitions don't actually need to be Ghost images, so simple copies of the contents will do.)

(2) A Track 0 backup, plus individual Ghost images of each partition.  This is essentially option 1 but choosing to use Ghost to backup the data partitions.

(3) A Ghost whole-disk image.  This is essentially option 2 with everything all together in one backup.  Note this may be the easiest to create, but because of its size it's harder to store.

If you're rebuilding everything on a new HDD, you don't have to partition it beforehand.  Ghost does need partitions to restore into, but partitioning is taken care of by restoring Track 0.  **

So start by restoring Track 0, which restores your MBR bootstrap code, DiskID, and your partition table.  By restoring the partition table, you have, in one fell swoop, defined your partition boundaries, and your disk is now "partitioned", in a manner of speaking--they're empty, raw partitions at this point, but it's partitioned.  Now you have something into which Ghost can pour the contents of the partition image.  After Ghost does that, you'll have a complete, usable partition.

If your backup strategy was to use Ghost images for your data partitions, restoring such an image will automatically convert a raw partition into whatever format, NTFS or FAT32, the original source was.

If your strategy was to make simple copies of the contents of data partitions, then you must first format the raw partition to either NTFS or FAT32 before you can copy the contents back into the new partition.  (Note the flexibility here--the new partition doesn't have to be the same format as the original.)

** caveat re: partitioning... you have five partitions, so you must be using an Extended primary partition with two or more logical volumes within it.  Restoring your partition table will only restore your primary partition layout, not the extended/logical partitions.  The total space of your Extended partition will be laid out, but not how it is subdivided.  You'll need to define its logical partitions by some other means--a normal partitioning utility or even Windows will do.

This may be confusing, so let me illustrate with an example.  Let's say your 5 partitions are laid out thusly:

NTFS primary + NTFS primary + extended (logical + logical + logical)

Restoring Track 0 would "partition" your new disk into:

(raw primary) + (raw primary) + (raw extended)

Restoring Ghost images (or formatting and copying contents) will restore the two primaries back to NTFS primaries, but the subdivisions of your extended partition haven't been defined yet.

Since the exact sizes are rarely critical, just use Windows Disk Management or any partitioning utility to carve your three logical volumes in the Extended space, and then you can fill them back up.

You're all giving me such an overwhelming support. All I can tell you is that last night my brain was busier than ever - I woke up ... my small and dark intelligence had been illuminated (at least I hope so) ... by your wonderful °input° [smiley=dankk2.gif]

NightOwl wrote:


Quote:

zeroing out a MBR

IMHO that can be done by *MbrWork* too.

*MbrWork 1.08:


Quote:

the various tasks and how to use them are in that *readme.txt* file

see attachment

Brian's link is somewhat different (older version).

All I need to know now is:

In which order should I chose the tasks ?

I want to backup the MBR > then clean the MBR > restore the cleaned (from possible virus) MBR to my 1st HDD.

without any img restore, mind! > Just have a clean MBR, also for later backups, unless I change anything, that's understood.

I understand step #1 = "backup first track" - of course  ::)

After that I still don't know > "Restore first track" would make no sense to me, cause there were no changes made at all. = 'zig' > 'zag'  ;D

Dan may be kind enough to tell me the further steps, because he's familiar with *MbrWork*

>>>> step #1 = "Backup First Track"
>>>> step #2 = ?
>
>
>

(After all I don't want to end up with a damaged PC.).

henriette   :-*

---

henriette wrote on Jun 16^th, 2012 at 8:53am:

Dan may be kind enough to tell me the further steps, because he's familiar with *MbrWork*

Yes, MbrWork is one of the small handful of Terabyte products that I'm familiar with, but don't count out Brian--he's our resident expert in all things Terabyte!




Quote:

All I need to know now is: In which order should I chose the tasks ? I want to backup the MBR > then clean the MBR > restore the cleaned (from possible virus) MBR to my 1st HDD.

I'm not clear on what you're asking.  Maybe I missed it earlier in the thread, but are you thinking your current MBR is infected and needs repair?  I thought you were just looking to backup your current MBR to protect against possible future problems.  Or are you simply asking in which order you should do things if/when disaster strikes in the future?  Or are you under the impression MBRs gradually get dirty over time and need occasional cleaning?

The answer to the latter is no--if your bootstrap code hasn't been infected, it is going to be identical to what it was on the day it was first put on your computer.  Your partition table should be just as it was when you last repartitioned.  These parts don't change through use.

Mbrwork is a DOS program, so you need to boot to real DOS to use it.  I have a DOS-bootable USB flash drive, so I put mbrwork.exe on that.  As Brian warned earlier, when you boot from a flash drive it becomes "Drive 0" and your main HDD becomes "Drive 1", so after you launch mbrwork.exe you use the "change active hard drive" option to make sure you're working on the correct disk.  (If you boot from a DOS-bootable CD, you don't need that step.)  To backup Track 0 for safekeeping, select "Backup First Track".  This puts a tiny .bin backup file on the flash drive.  Restoring Track 0 is similar--boot from flash drive, switch to "Drive 1", then "Restore First Track".  In the interim, you can copy the .bin file to some other medium if you want, then move it back to the flash drive if/when you need to restore.

If you're trying to repair your MBR and don't have a prior backup, use the above steps to backup Track 0.  This gives you something to return to in case your repair attempts go wrong.  Then use MbrWork to "Install standard MBR code".  This will replace any infected bootstrap code with a known-good MBR.  That code should work fine unless you've got some kind of multiboot system.  (And if it doesn't, you've got your pre-repair Track 0 to return to while you figure out a Plan B.)

Does this answer your question?

Dan wrote:


Quote:

are you thinking your current MBR is infected and needs repair?

No  ;)


Quote:

Or are you under the impression MBRs gradually get dirty over time and need occasional cleaning?

I thought it might, but you assure me "The answer is no.".   :) :)


Quote:

I thought you were just looking to backup your current MBR to protect against possible future problems.

Yes, actually I thought about what might happen if I'd chose the wrong HDD by mistake  :o

So I decided to only backup my current MBR.
That way I'd be on the safe side, if anything should ever be wrong in the future. Correct ?

I'd backup the MBR whenever I'd make any changes:

NightOwl wrote:

Quote:

If you do any HDD changes to the basic structure--like any changing of the partition sizes, number of partitions, etc.--you need to make an updated backup of the MBR--have to keep it up to date.  If you don't make any changes, ever, then that original backup will remain valid.

Dan wrote:

Quote:

Or are you simply asking in which order you should do things if/when disaster strikes in the future?

That as well.

May I assume that in such case a restore of the (latest) MBR backup would fix the problem (see below!) :-?

Steps (as I take from your post):

1. I boot from a DOS-bootable CD (UBCD). < I DON'T have to 'switch to drive X'. .

2. To backup Track 0 for safekeeping, I select "Backup First Track".

Dan wrote:

Quote:

This puts a tiny .bin backup file on the flash drive

Well, ... where will it be 'put' if I don't use a flash drive  :-/

3. copy the .bin file to floppy disk ??? > move it back to the flash drive < I don't use a flash drive --> WHAT now ? if/when I need to restore.
(same problem as above.).

4. (Only if necessary some day):
To restore Track 0 > UBCD > then "Restore First Track".


Quote:

If you're trying to repair your MBR and don't have a prior backup, use the above steps to backup Track 0.  This gives you something to return to in case your repair attempts go wrong.  Then use MbrWork to "Install standard MBR code".  This will replace any infected bootstrap code with a known-good MBR

The above would be #5.

----> I still got the problem: how to GET the *.bin file on a floppy disk  ::) ... IMHO there's no way.

I deeply regret my lack of knowledge ...  :-[

henriette   

@ henriette


Quote:

----> I still got the problem: how to GET the *.bin file on a floppy disk   ... IMHO there's no way.

Do you know the Simon and Garfunkel song *50 Ways to Leave Your Lover*?  Well, that's about how many different ways you can do something when using DOS or Windows  :D !


Brian wrote on Jun 15^th, 2012 at 5:29pm:

To backup the First Track you must be running MBRWork from writable media.

From this statement, I took this to mean MBRWork defaults to writing the MBR backup to the media and file directory from which MBRWork loads from.  This is not an uncommon DOS program behavior.  On the other hand, many DOS programs allow you to change the destination where an output file will be saved.  I'm going to have to take a look at MBRWork to see if any such option exists--but, the *readme.txt* file referenced previously above is certainly of no help!

But, if the above statement is *true*--then you will not be able to use MBRWork from the Ultimate Boot CD--or any bootable CD from which you load MBRWork--because DOS does not support writing to optical media (Ghost does--from within the DOS Ghost program--but DOS by itself does not).





So, here's one of the *50 ways*--most DOS programs are *stand alone*--you don't have to start them from a boot disk, and there don't have to be other helper files (except the ones that come with the DOS program itself--but, those type of programs are the big, complicated ones):

1.  While in Windows, create a new floppy disk that's dedicated to MBRWork by placing the MBRWork.exe program on it (most new floppy disks come pre-formatted--so you don't have to do any formatting, and the floppy does not need to be a boot disk either--just a plain storage floppy disk).

2.  Your system has a floppy drive--that's what you use to boot to DOS and run Ghost 2003--so boot using your Ghost boot floppy--if Ghost starts *automatically* (i.e. your autoexec.bat loads Ghost.exe for you), simply quit Ghost and you will be at the A:\ prompt.

3.  Now eject your Ghost boot floppy, and place the MBRWork floppy in the A:\ drive.  Type *mbrworks.exe* and MBRWork will load from that floppy.

4.  Once MBRWork is loaded--you can proceed to make the backup.  Because you loaded MBRWork form the MBRWork floppy in drive A:\, your backup *.bin* file should be saved to your MBRWork dedicated floppy (check to make sure it's there).  Put it away for safe keeping, and you're done!




And here's another one to the *50 ways*  ;) :

1.  If you're booting from the Ultimate Boot CD (or any other bootable optical disc that's booting to DOS), and load MBRWork from it--in order to boot to DOS from an optical disc, a *virtual floppy drive* is created, and it will be assigned the A:\ drive letter.  But, your physical floppy drive still exists (assuming you have one in the first place--and you do).  It will no longer be the A:\ drive because the bootable optical disc will have taken that drive letter.  But, DOS is more than happy to support two floppy drives!  So, your physical floppy drive is now B:\!

2.  So, if MBRWork is automatically loaded when booting from the Ultimate Boot CD, exit the program, and you should be at the *virtual floppy drive* A:\ prompt.  Type *B:* and press *Enter* to change the focus of the DOS prompt from A: to B:.  (Technically, it might not be the A:\ drive at the DOS prompt--if MBRWork is loaded from a sub-directory on the optical disc, then the DOS prompt will be focused on the optical drive's drive letter, and possibly sub-directory--still same procedure though, just type *B:* at whatever prompt you are at and press *Enter*.)

3.  Put your dedicated MBRWork floppy, as mentioned above, into the physical drive, type *mbrwork.exe* and load MBRWork from the physical floppy disk.  Tell MBRWork to save your first track, and the *.bin* file should be saved to the floppy disk at drive letter B:\!  You're done--put that floppy disk away for safe keeping.


Give either method a try and see what happens--you can't cause any harm to your system if you are creating backups--it's only when you do something that *writes* to your HDD (such as doing a restore of the MBR) that you might get in trouble--if you use the wrong *.bin* file that's outdated, or for a different HDD or computer!

If and when you might need to restore that MBR *.bin* file, simply boot to DOS, put the MBRWork dedicated floppy with that backed up MBR *.bin* file on it in the floppy drive, change the DOS focus to that drive (either A:\ or B:\ depending on the situation), load MBRWork, and choose the restore function.

NightOwl wrote on Jun 17^th, 2012 at 10:30am:

re: "To backup the First Track you must be running MBRWork from writable media." From this statement, I took this to mean MBRWork defaults to writing the MBR backup to the media and file directory from which MBRWork loads from.

In technical terms, the "Backup.." and "Restore First Track" options read/write to the DOS environment's CWD ("Current Working Directory").

Some Windows users may not be familiar with the concept.  The CWD is the active directory--where your command prompt is sitting at the moment.  The DOS environment is often configured to explicitly state the CWD with the command prompt.  Thus, you'll see your flashing cursor, waiting for your command, immediately following something like "A:\>" or "C:\DOS>".  (The ">" is the command prompt, and the part before it is the CWD.)

Programs need not reside in the CWD to be launched.  If they're in some other directory, they can be launched by calling them with the full pathname--ala, "c:\util\mbrwork", for example.  (Aside: The full pathname can be omitted if the executable's location is a directory in the DOS environment's "path" . . . but that's another topic.)

I don't use UBCD so don't know how it's structured.  But for the purposes of illustration, let's say when it boots you're left at (or can escape to) the A:> prompt, your floppy drive is B:, and the mbrwork.exe file is in the R:\TOOLS directory.  You can issue the following commands:

A:\> b:
B:\> r:\tools\mbrwork

The first command changes the current working drive from A: to B:.  Until it's changed, B:'s CWD is its root, so B:\ is now your CWD.  (Aside: in the DOS world, "B:" denotes a drive, while "B:\" is a directory.)  You can launch MbrWork from the CD (drive R:, in this illustration) by explicitly calling it, but B:\ is still your CWD.  When you exit MbrWork, you'll be back at the B:\> prompt.  While you're in MbrWork, the "Backup/Restore First Track" functions will read/write to the B:\ directory.

An even easier option is to use MbrWork's "Capture Sectors" or "Restore Sectors" function instead of "Backup/Restore First Track".  (Caution: remember, Brian warned the sample readme file mentioned earlier was for an old version, so it doesn't show these options.  I trust henriette is actually exploring MbrWork for real and not looking only at the old readme.)  "Capture/Restore Sectors" is like "Backup/Restore First Track" except you get to dictate the variables--how many sectors, starting location, and filename.  So if you're running MbrWork from CD you can select "Capture Sectors" from the menu, then tell it to start from Sector 0, capture 63 sectors, and save to "b:\mymbr.bin" (or whatever you want to name it).  "Backup First Track" is just "Capture Sectors" prescripted to save 63 sectors from LBA 0 to "{cwd}\back0.bin".  (We'll ignore for this discussion the recent thread about when it's not 63 sectors.)

Finally, if henriette's motherboard is modern enough it should be able to see a USB flash drive if it's present at boot time.  Insert a flash drive before booting from the UBCD, and if the main HDD has no FAT/FAT32 partitions the flash drive will probably become drive C:.  Like above, you can run MbrWork from CD and save Track 0 to the flash drive as something like "c:\backups\asusmbr.bin", for instance.  (Warning: DOS is not a "plug-and-play" OS, so the flash drive must be present when DOS boots.  If it's inserted afterward, DOS won't see it.)

@ henriette

Well, there you go!  We now have the 3rd of *50 ways to leave your lover*--err I mean backup to the floppy drive!

Anyone else have something to add!

@ Dan Goodell


Dan Goodell wrote on Jun 17^th, 2012 at 2:01pm:

In technical terms, the "Backup.." and "Restore First Track" options read/write to the DOS environment's CWD ("Current Working Directory"). Some Windows users may not be familiar with the concept.The CWD is the active directory--where your command prompt is sitting at the moment.

Thank you for that explanation!  Over the years I have struggled with that issue with certain programs--but never knew there was an easy way around the problem!

For many years here, folks have complained about getting a Ghost error when booted to DOS via a bootable optical disc--and getting an error that Ghost could not write the error file!

That was because the Ghost default was to write the error file to the A: drive--unless a command line switch was used to launch Ghost that redirected the output file elsewhere--could be any available drive that DOS could see--floppy, any FAT based partition on local HDD (but not NTFS partitions), USB flash drive or external USB HDD--those had to be mounted in some way through DOS drivers or by the BIOS if that function was supported.

I'm not sure if your above technique will also over-ride the Ghost default (but, my best guess is *Yes*!).

When booted from an optical disc, the *virtual floppy drive* is a read only drive--you can not write to it--and thus the error message about not being able to write the error file by Ghost.  So, just have autoexec.bat switch to the B: drive (making it the *current working directory), and then call the Ghost program from the *virtual floppy* A: drive--have a floppy disk in the physical floppy drive and now you will get the error file saved to the floppy disk!  Sweet!  I'll have to give that a try.

NightOwl wrote on Jun 17^th, 2012 at 3:11pm:

When booted from an optical disc, the *virtual floppy drive* is a read only drive--you can not write to it--and thus the error message about not being able to write the error file by Ghost.So, just have autoexec.bat switch to the B: drive (making it the *current working directory), and then call the Ghost program from the *virtual floppy* A: drive--have a floppy disk in the physical floppy drive and now you will get the error file saved to the floppy disk!Sweet!I'll have to give that a try.

Yes, that will work, though bear in mind it expects you to have that floppy disk in there.  If you don't, you could get other error msgs.

Here's another alternative.  I've long made my own customized bootable CDs, and a trick I use in config.sys and autoexec.bat is to initialize a ramdrive at boot time and then run as much as possible from the ramdrive.  It's faster than reading files from the CD and provides a ready place with write access for programs, but this technique is more complex to setup.

Programs can write to the ramdrive, so I don't have to worry about whether the system has a floppy drive or flash drive or writable FAT/FAT32 partition just to run some utilities or diagnostics.  OTOH, the ramdrive disappears when you shutdown, so if a program does create a record you want to save, you have to remember to copy it somewhere else before you lose it.

Thanks guys. I'm a lot wiser now.

The following could suit users without a floppy drive and who don't have or can't make a DOS USB flash drive.

Download the free TBOSDT from...

http://www.terabyteunlimited.com/tbosdt.htm#download

Unzip and go to the dos_tbos folder
double click maketbos.exe
tick all the optional components
select the drive letter of your flash drive
accept USB Mode Normal

Boot from the flash drive
at the > prompt type  tbosdt  and press <Enter>
at the @C:\> prompt type  list hd 1 /u and press <Enter>

You will see the partitions on hd 1. If hd 1 isn't your primary HD then try list hd 2 /u. Or list hd 3 /u    hd 0 is the flash drive. When you have identified your HD, type (assuming your HD is 1)
copy sectors 1 0 63 mbrb and press <Enter>
1 is the HD number
0 is the starting LBA
63 is the number of sectors to copy
mbrb can be any name. It doesn't need a file extension

If your HD was 2 then the line would be
copy sectors 2 0 63 mbrb and press <Enter>

That's it. The MBR (First Track) of your HD has been backed up to the flash drive.

To restore the MBR, use list hd 1 /u (or use your HD number)  If your HD is 1 then type

copy sectors 1 0 63 mbrb /w and press <Enter>
read the confirmation text and if appropriate press Y

Now type  list hd 1 /u and press <Enter>  (or use your HD number) and you should see all your partitions.

For safety, only have your primary HD connected for the restore procedure. You don't want to put the saved MBR on the wrong HD. If you can't remember the name of your backup, look at the flash drive files in Windows. The backup is the file without an extension.

Hiya 

I'm ageing fast, no wiser though.

This subject is getting extremely complicated for me. 

I have tried NightOwl's '50 ways' - 2, that is (not having read the latest posts, yet.).


Quote:

you will not be able to use MBRWork from the Ultimate Boot CD--or any bootable CD from which you load MBRWork--because DOS does not support writing to optical media

True. I've tried it first, anyway, as you described it - with UBCD - to no avail.

Then I tried GHOST >> both set of 2 CD/DVD boot floppies and Ghost standard boot floppy.


Quote:

most DOS programs are *stand alone*--you don't have to start them from a boot disk

That's of great help!!! [smiley=thumbup.gif]
Had created a boot floppy before - thought it had to be bootable to work ...!

> created floppy, just *MBRWORK.EXE* on it for saving *.bin(s) onto. Write protection is disabled!

> Booted with the 2-set Ghost floppies.

> After quitting Ghost I had a DOS prompt: "A:\GHOST>" (!)
Tried to change to a clear A:\prompt --- obviously I can't remember/find the correct command.
On the web it says e.g. "a:* would do. As far as I recall I've tried it with a ">" at the end, as well.

Whatever I tried > "bad command or file name"  >:(

> Booted with Ghost standard floppy: same result.

> Also when typing "mbrwork.exe" (still after A:\GHOST), of course, it would not load.

... "the Duck got stuck"   ::)

Can you tell me, please, what the h*** did I do wrong now ? ... just failed with the commands ?

Now, the last 3 posts are for insiders WOW ... myomy ...

... on the other hand: learning never ends ::)

henriette  :-* :-* :-*  <one for each of you busy guys>

@ henriette


Quote:

> After quitting Ghost I had a DOS prompt: "A:\GHOST>" (!) Tried to change to a clearA:\prompt --- obviously I can't remember/find the correct command.

Ah--forgot where the Ghost-made boot disks leave you after quiting Ghost--those boot disks have Ghost.exe placed in a sub-directory named *Ghost*--and not in the *root directory* of the floppy disk--which is where the *mbrwork.exe* is on that dedicated floppy.

At the *A:\Ghost>* prompt, type *cd ..*--that's Change Directory, a space, and the *two periods* is the command to go up to the next level in the DOS directory tree--which in this case would be *A:\>*.  Now you should be able to type the MBRWork.exe command and get the desired results. 

(You can use the *change directory* and *two periods* without the space between, but that's not technically the best way to do it--if you actually type in the directory you're wanting to change to--if there isn't a space between the *cd* and directory name, DOS will say it's not a supported command.)

Alternatively, (yes, we're on our way to *50 ways* to load a DOS program from a floppy!), you could create a sub-directory on that *MBRWork* floppy called *Ghost* and put the *mbrwork.exe* in that sub-directory.  Now DOS will find the program because its *focus* is still on the sub-directory of *Ghost*.  Now, you don't have to shift the DOS focus to *A:\*--the *.bin* file will be in that *Ghost* sub-directory when done.

Alternatively ( :D ), we could edit your autoexec.bat on your Ghost boot disk to change the DOS prompt focus back to the *A:\* once you exit Ghost.

Alternatively, ( ;D ) we could use the DOS command showing the actual path we want: *cd A:\* instead of the two period in the *change directory* command--this one makes more sense if you are several sub-directories deep in the DOS directory tree and you don't want to type *cd ..* multiple times--because it moves up only one directory at a time.


Quote:

This subject is getting extremely complicated for me.

Yes, we have gone *off the deep end* regarding more esoteric *50 ways*--but, you only need one way that works for you--the others are for those who need alternate avenues to the same end.  You can ignore all the added *fluff*!  But, sometimes those more complicated *ways* are needed for some situations.

Okay, henriette, let's summarize.  Now we know you've got a Ghost floppy to boot from and another (non-bootable) floppy with mbrwork.exe on it.  So here are the steps you want to follow:

1.  For the sake of safety, disconnect all other hard disks or flash drives so MbrWork only sees one hard disk.  (If you leave flash drives or other HDDs connected, pay attention to step 6.)

2.  Boot from the Ghost floppy and escape to the DOS prompt.  You'll be left at "A:\Ghost".

3.  Type "cd \" and press [Enter].  You should now be at "A:\".

4.  Remove the Ghost floppy and insert the MbrWork floppy.

5.  Type "mbrwork" and press [Enter].  This launches the MbrWork utility.

6.  If the MbrWork menu offers option 7 ("Change active hard disk"), confirm that you're working on the correct HDD (see next post).

7.  Press "1" to backup the first track.

8.  Press "e" to quit MbrWork.  You'll be returned to the A:\> prompt.

9.  Type "dir" and press [Enter].  This lists the files on the floppy.  Confirm that you now have a file named "BACK0   BIN" on the floppy.  It's size should be about 32KB.  (Tip: DOS won't show the "." before the filename extension.)

MBRWORK - How to tell which HDD you're working on:

MbrWork displays hard disks only--EIDE/PATA, SATA, and connected external HDDs.  CD/DVD drives and floppy drives won't be shown.  Beware: most USB flash drives emulate a hard disk, so *will be enumerated* if they are plugged in.

If there is more than one HDD enumerated, MbrWork will include option 7 ("Change active hard drive") on the menu.  The menu option is suppressed if there is only one HDD.

HDD enumeration (e.g., "HD0" vs "HD1") can change depending on how the system has been booted.  Therefore, you should get into the habit of looking at the partition table to see if it looks like the HDD you mean to be working on.  MbrWork assumes you want to work on HD0 unless you select menu option #7 and switch to another HDD.

If you boot from your main HDD, it will be HD0 and other HDDs (secondaries, externals, and flash drives) will be HD1 and above.  If you boot from a flash drive, the flash drive will be HD0 and other HDDs (including your main HDD) will be HD1 and above.  If you boot from floppy or from CD/DVD, your main HDD will probably be HD0, but get yourself into the habit of checking to be sure.

Clues to look for in the partition table:

• There are four rows in the partition table.  Are there entries in more than one row (i.e., more than one partition)?  Flash drives will have only a single partition.  Hard disks may have one or more.

• What file system (see column 6) is the partition using?  NTFS partitions will be shown as "7".  FAT32 partitions will be shown as "b" or "c".  Flash drives will typically have a single FAT32 partition.  Hard disks typically have one or more NTFS partitions.

• If there is more than one HDD, the MbrWork menu will include option 7 (Change active hard drive).  Switch to the other HDDs and compare partition tables to see if one looks more right than the other.

This is what the TBOSDT lines look like.

http://i16.photobucket.com/albums/b16/bjkdegree/tbosdt-mbr.gif

@ NightOwl

Yeah! Yeah! Yeah! ... ~~~ dee dle dee dle dumm ~~~

It worked  ;D ;D ;D

... and I'm happy

~~~Oh, what a beautiful mo:::::rning~~~

ahem, sorry for my sing-along.


Quote:

*A:\Ghost>* prompt, type *cd ..*,  a space, and the *two periods* is the command to go up to the next level in the DOS directory tree--which in this case would be *A:\>*.  Now you should be able to type the MBRWork.exe command and get the desired results.

Yesssss, now it worked :=)))

I've tried *cd* yesterday, already - just without the space and the two periods [dots] ,,,

First thing today was to look for mail > found your *new* instructions & did as told.

It's done within less than a second (*backup First Track* I mean).

To make sure the *.bin is actually on my floppy > I checked.
> = "BACK0.BIN" | 32kB | date.

Thank you all for making me so happy > see attachment for you fabulous guys

(Going to read the latest posts now).

henriette

---

Thanks to Dan's additional, most detailed posts, which are most appreciated!  [smiley=dankk2.gif]

As I posted above, I followed NightOwl's email notification instructions, before I came to read the posts in here.


Quote:

For the sake of safety, disconnect all other hard disks or flash drives so MbrWork only sees one hard disk

NightOwl wrote:

Quote:

you can't cause any harm to your system if you are creating backups--it's only when you do something that *writes* to your HDD (such as doing a restore of the MBR) that you might get in trouble--if you use the wrong *.bin* file that's outdated or for a different HDD

I will take care of the latter (red), and follow your above instructions if (ever) I'll do a restore :o

henriette

@ henriette


henriette wrote on Jun 19^th, 2012 at 4:12am:

First thing today was to look for mail > found your *new* instructions & did as told.

henriette wrote on Jun 19^th, 2012 at 5:10am:

As I posted above, I followed NightOwl's email notification instructions, before I came to read the posts in here.

Appreciate the compliments--but I'm concerned--I didn't email you any instructions!  All of my communications have been postings on the forum.

That's not my way of doing things here on the forum.  I like the communications to be posted for all to see regarding anything we are discussing in a thread.  I rarely use any *Private Messages* (PM's), and almost never emails.  I know sometimes it might be *more efficient* to use non-forum methods of communication--but, then I think the forum community as a whole is being left out, and *suffers* from such behind the scene activity.

I'm hoping that you misread the source of the *email* you are referring to, and it came from someone else here on the forum--maybe mentioning my name or something.

If someone is impersonating me--I guess I need to know that!  If it really looks like the email came from me, we need to *talk* using *PM's* (private messaging).

My concern is that if someone who looks trustworthy is impersonating me--then you are at high risk of getting that MBR or other virus, trojan malware, or other malware of some sort.  Opening an attachment or clicking on a link in such an email could be a real problem!

Make sure you are using an antivirus program that scans emails, up to date definitions--but, even then, clicking an attachment or link may still cause an infection--these types of emails probably will not be caught by the antivirus program!

So let me know the result of your re-checking the email source.  Don't delete it if you haven't already--may need to see information from it, if possible.

Did anyone else here, per chance, send henriette an email?

@ Dan Goodell


Dan Goodell wrote on Jun 18^th, 2012 at 8:33pm:

3.Type "cd \" and press [Enter].You should now be at "A:\".

Ah, yes, the more direct way to get to the *root directory* of a given drive in DOS!  So, there we go--adding another *50 ways* to get to the root directory in DOS using the *change directory* command!

For the record, *cd* is the short hand abbreviation that DOS allows for the longer command name CHDIR.

(We're embarking on another tangent here, henriette, so feel free to disregard if you wish.)


NightOwl wrote on Jun 19^th, 2012 at 10:14am:

re: Type "cd \" and press [Enter].You should now be at "A:\". Ah, yes, the more direct way to get to the *root directory* of a given drive in DOS!

I don't know if "given drive" is semantically correct . . . it changes the directory on the current drive, whereas "cd a:\" would change the "given drive", and "a:" is the given.

DOS internally keeps track of the "working directory" on each drive, as well as the "current drive"--as you say, the drive with focus.

To switch the current drive, simply type "a:" or "c:".

(Aside:  DOS commands are not case-sensitive.  The command line is internally converted to uppercase by the command interpreter--e.g., io.sys, so case is irrelevant.)

DOS was beautiful in that it followed rigid rules.  Drives are denoted by a letter followed by a colon.  Backslashes denote directories.  The two special directory names, "." (current directory) and ".." (parent directory), are references that make the backslash relative instead of absolute.

"A:" refers to drive A:, "A:\" refers to the root directory of drive A:, and "\" refers to the root directory of the current drive.

DOS internally keeps track of the working directory of each drive, so if the working directory of C: is C:\BIN and the working directory of A: is A:\BACKUP, then typing "a:" or "c:" switches directly between A:\BACKUP and C:\BIN.

The CHDIR command (aka, "CD") changes the working directory.  Entering "cd foobar" is different from "cd \foobar", which is different from "cd c:\foobar", which is different from "cd c:foobar".

For illustration, suppose the working drive of C: is c:\dos\files, your current drive is A:, and the current working directory is a:\data\stuff.  Put all the rules together and you have the following very consistent and predictable results:

command:	result:
cd foobar	changes A: working dir to a:\data\stuff\foobar
cd \foobar	changes A: working dir to a:\foobar
cd .\foobar	changes A: working dir to a:\data\stuff\foobar
cd ..\foobar	changes A: working dir to a:\data\foobar
cd c:foobar	changes C: working dir to c:\dos\files\foobar
cd c:\foobar	changes C: working dir to c:\foobar
cd c:.\foobar	changes C: working dir to c:\dos\files\foobar
cd c:..\foobar	changes C: working dir to c:\dos\foobar
cd c:..\..\foobar	changes C: working dir to c:\foobar

(Note the changes to C: won't be apparent while A: is the current drive, but when you enter "c:" to switch the current drive you'll see the change.)

All this versatility isn't just for the convenience of the user, it's also for the benefit of programs.  A program can be installed in a directory with its own special subdirectories, and then be able to access files without having to worry about whether the user installed it somewhere other than the default or changed the name of the installation directory.

I'm sure you've heard stories of brain-dead programs that would only install to the C: drive or would only install to a specific, hard-coded directory.  That's not DOS's fault--it provided the options but the programmer didn't use them.

@ NightOwl


Quote:

I'm concerned--I didn't email you any instructions!  All of my communications have been postings on the forum. ... My concern is that if someone ... is impersonating me ... Opening an attachment or clicking on a link in such an email could be a real problem!

You don't have to be concerned, please read the attachment = "Topic Notification", as I receive it. --- (sorry, formatting went down the drain > *.eml to *.txt).
I called it *email notification instructions* in my post ::)

Facts:

Email *program* = Outlook Express > run with IE in private (newsletters)!
> I'm taking extra care of e.g. sorting out spam, deleting, not opening attachments etc. - in case of doubt I read the source code first, etc. etc.

Antivirus program = *ESET NOD32 v5* - NO freeware.
Always up to date definitions! Scans all emails.

There's no U.S. link available - so I've picked the u.k.:
http://www.eset.co.uk/Home/Smart-Security

As for the notification:
I don't receive the °header° only but also the content of the post + link.

After the link the line:
No more notifications will be sent until you visit the topic again.

Always had been that way. Also from other boards/forums. 

Still concerned  ?

henriette 

---

@ Dan


Quote:

We're embarking on another tangent here, henriette, so feel free to disregard if you wish

No way  :)

DOS is a most interesting *part* of the computer - its heart, if I may say so.

In other words: when I boot into DOS, I feel kinda *within* my PC ... just the fact that I lack in commands ---
*to lack the knack*, as the Brits say ;D

Mind: both my XP and my keyboard [QWERTZ] are all German. When it comes to DOS, though, it's all English >>> meaning also, I have to take the picture of an English keyboard [QWERTY] in order to press the right keys.

No big problem, except > never forget that Z=Y!!! < most important when making changes in BIOS, after which you're asked to *save changes* ---> YES = ZES! ;)

I know there are tools where you can switch a German keyboard to English ... I refuse to try those odd tools!

Oh, I'm reading & trying to learn with utmost interest what you teach about DOS and it's commands.

henriette   :)

@ henriette


henriette wrote on Jun 20^th, 2012 at 6:34am:

Still concerned?

Nope! (Whew!).  You were talking *apples*, and I was thinking *oranges*!  The forum's email notification that a new replies have been added to a topic is not a problem at all.   

It's just the way you worded your response--I thought you were saying you got an email directly from me with the information on how to work with the *change directory* command in it, as opposed to a notification that new reply(s) were available on the forum.

@ Dan Goodell


Dan Goodell wrote on Jun 19^th, 2012 at 5:43pm:

(We're embarking on another tangent here,

Nice--*Summer School* session has started  :) !


Dan Goodell wrote on Jun 19^th, 2012 at 5:43pm:

I don't know if "given drive" is semantically correct . . .

Indeed!  Bad semantics--computers and software really don't like that, do they  ;) !

One minor addition to your explanation:


Dan Goodell wrote on Jun 19^th, 2012 at 5:43pm:

For illustration, suppose the working drive of C: is c:\dos\files, your current drive is A:, and the current working directory is a:\data\stuff.

I think the directory *foobar* has to actually exist in all the locations that you use *cd* to change to--otherwise I get the error message *Invalid directory*!



Dan Goodell wrote on Jun 19^th, 2012 at 5:43pm:

(Aside:DOS commands are not case-sensitive.The command line is internally converted to uppercase by the command interpreter--e.g., io.sys, so case is irrelevant.)

That must not have been *always* true.  Way back when, I can remember instructions saying DOS commands need to be all uppercase.  So, I assume somewhere along the line--probably long before DOS v6.22, the command interpreter wasn't so *smart*.

@ henriette


henriette wrote on Jun 20^th, 2012 at 7:33am:

when I boot into DOS, I feel kinda *within* my PC ... just the fact that I lack in commands ---

My above reference to the [CHDIR] command--you can find all the DOS 6.22 commands at the site:  MS-DOS v6.22 Help: Command Reference.

I use it often when working out how to do things in DOS.

Just for the record--if opening a *command* window from within Windows--some *DOS* commands are different now compared to what they were back in the DOS 6.22 days.  So, you have to look up the correct *syntax* for whatever version of Windows you are currently using!


henriette wrote on Jun 20^th, 2012 at 7:33am:

I know there are tools where you can switch a German keyboard to English ... I refuse to try those odd tools!

They're not so *odd*!  I think there are both DOS tools (drivers) and Windows tools for doing that--if you want to start another topic on how to do that (if it is of any value to you)--I'm sure we can probably walk you through it.

Dan,

While we are on a tangent can you explain what this does...

CD /d %~dp0

I've used it to change to the directory in use but I don't entirely understand what I've done.

NightOwl wrote on Jun 20^th, 2012 at 9:40am:

I think the directory *foobar* has to actually exist in all the locations that you use *cd* to change to--otherwise I get the error message *Invalid directory*!

Correct.




Quote:

re: "The command line is internally converted to uppercase by the command interpreter--e.g., io.sys, so case is irrelevant." That must not have been *always* true. Way back when, I can remember instructions saying DOS commands need to be all uppercase.

No, DOS commands have always been case-insensitive.  I remember, ages ago when I was teaching myself assembly language, I reverse engineered the DOS 2.1 and 3.3 command interpeters to see how they worked.  I could see in the assembly code where they read the keyboard buffer and looped alpha chars through an AND mask to strip out bit-5, effectively turning them into uppercase.

Aside: Take a look at a hexadecimal ASCII chart and you may notice the uppercase alphabet and lowercase alphabet differ only by bit-5.  For example, a "T" is 0x54 (binary 01010100) while "t" is 0x74 (binary 01110100).  If you clear/set bit-5 (third from the left), you can force the character to be upper/lower case.  The ASCII sequence was purposely designed that way.

Back then, memory space was precious so program code had to be lean and mean.  It was much more efficient to store the command table (inside the interpreter) all in one case, convert the keyboard command to the same case with an efficient, couple-byte program loop, then do a direct table comparison to find the jump vector to the command's subroutine.

I suppose I could point out that programmers might need to be alert to case within their program code sometimes, particularly if your program was trying to find comparisons to command or filename strings elsewhere.  But the command line itself, having to pass through DOS's command interpreter, has always been case insensitive.

Brian wrote on Jun 20^th, 2012 at 6:07pm:

While we are on a tangent can you explain what this does... CD /d %~dp0

I believe that only works in the Windows command interpreter (cmd.exe), so it's technically not a DOS command.

(Aside: Lurkers need to understand the command prompt window in Windows--aka, a "DOS box"--is not DOS at all.  It is a Windows environment running a DOS-like emulator.)

The "%0" is derived from DOS, and is a variable referring to the first parameter on the command line.  In the case of a batch file, that would be the name of the batch file.  Similarly, the variables %1 through %9 refer to the other parameters on the command line.  Thus, in the command "copy  file1  file2", %0 is "copy", %1 is "file1", and %2 is "file2".  In batch files, it's one method by which you can pass variables to the batch file.

The "~dp" are modifiers that mean expand %0 to get its drive and/or full pathname.

For instance, if your batch file is "D:\Me\Desktop\test.bat", %~d0 is "D:", %~p0 is "\Me\Desktop\", and %~dp0 is "D:\Me\Desktop\".

%0 depends on how you call the batch file.  If you use the command "test", %0 is "test".  If you use the command "test.bat", %0 is "test.bat".  If you use "d:\me\desktop\test", %0 is "d:\me\desktop\test".

Lastly, the "/d" takes the place of two commands: switch the working directory, and switch the current drive.  It's the same as having the following commands in your batch file:

cd %~dp0	(e.g. "cd d:\me\desktop")
%~d0	(e.g., "d:")

Dan,

That's correct. I was running CD /d %~dp0 in a WinPE. Your explanation has certainly helped me understand why it works. Thanks.

Some time ago I was interested in auto running apps when booted from a WinPE USB flash drive. You never know which drive letter the flash drive will adopt in the WinPE as it depends on the number of your HD partitions. I used Active@ Boot Disk. The Active@ WinPE has a default folder called User_Files (for your own files of course). There is another default folder called BootDisk_Scripts. If you put a batch file in this folder (.cmd extension) it will run when the WinPE loads.

For example, if I wanted A43 to auto run when the WinPE loaded I'd use a batch file containing..

CD /d %~dp0
CD \User_Files\A43
start a43.exe

The following doesn't work because the drive letter shown in the command window remains at X: instead of the drive letter of the flash drive and A43 can't be found ...

CD \User_Files\A43
start a43.exe

But I was really more interested in running auto restores from a flash drive and from WinPE installed on the HD.

@NightOwl

wrote Reply #55 - Yesterday at 16:30:34

Quote:

You were talking *apples*, and I was thinking *oranges*! ... It's just the way you worded your response

There you see > my insufficient language skills - call it *crapitude*  ;D

Glad that matter's sorted out now  :) 

Reply #57 - Yesterday at 17:02:49

Quote:

you can find all the DOS 6.22 commands at the site:  http://www.vfrazee.com/ms-dos/6.22/help/index.htm MS-DOS v6.22 Help: Command Reference.

Excellent, thanks a lot!

> "tools where you can switch a German keyboard to English":

Quote:

I think there are both DOS tools (drivers) and Windows tools for doing that--if you want to start another topic on how to do that (if it is of any value to you)--I'm sure we can probably walk you through it.

I don't really need that. It's mainly the special caracters which are different. I can handle that   ;)


Quote:

back in the DOS 6.22 days

hmmmm ?
Are you talking about the *real* DOS 6.22 vs MS/PC-DOS 6.22 which I got  :-?

This link may be interesting:
http://en.wikipedia.org/wiki/MS-DOS

@ Dan

As for the DOS/MS-DOS/PC-DOS/ lessons:
Great °stuff°  [smiley=thumbup.gif]

Thanks to Brian's question:
Most interesting, also, the *DOS-box* [Windows command interpreter (cmd.exe)]!!!  [smiley=thumbup.gif]

@ all

> Question Changing topic > this topic

Since I started this thread, the subject line has never changed, although we're on several different *topics*.
Is it possible to change the *subject line* WITHIN a  thread - WITHOUT *losing* the thread ? If so, why are we still working under:
"Ghost 2003, Img XP > DVD, INCOMPLETE ??"

...ooooh, just hope you understand what I mean ...  ::)

henriette 

@ henriette


henriette wrote on Jun 21^st, 2012 at 8:07am:

hmmmm ? Are you talking about the *real* DOS 6.22 vs MS/PC-DOS 6.22 which I got

MS DOS is DOS supplied by Microsoft.

PC-DOS is DOS supplied by IBM:  IBM PC DOS (full name: The IBM Personal Computer Disk Operating System)


Quote:

The DOS INT 21h function 30h get DOS version returns OEM code 00h for IBM instead of FFh for Microsoft. This is relevant for DOS 7, because various features introduced in MS DOS 7 (a part of Windows 95) are not supported in PC DOS 7, and vice versa, e.g., MS DOS 7 does not support REXX, and PC DOS 7 does not support FAT32

Quote:

PC DOS 7.10 IBM produced PC DOS 7.10 which was based on PC DOS 2000 and added support for LBA and FAT32 partitions. This version of DOS was never released in retail but was used in several IBM products such as the IBM ServerGuide Scripting Toolkit. This version of DOS has also appeared in Norton Ghost from Symantec. Version 7.10 is returned to applications, since this is usually a test for support of FAT32. Most builds of this version of DOS are limited to the kernel files IBMBIO.COM, IBMDOS.COM and COMMAND.COM. The updated programs FDISK32, FORMAT32 allow one to prepare FAT32 disks.

So, Symantec licensed the use of PC-DOS in Ghost--instead of licensing MS-DOS.  You therefore are using PC-DOS v7.10--not v6.22.

You can add MS-DOS to the Ghost Boot Wizard--one of the wizard's pages has the option for doing this.  All you need is the floppy boot disk for Win98SE OEM.  You can download it from here:  Bootdisk.com--just choose it from the list.  Run the downloaded file with a blank floppy in your drive, and the Win98se boot floppy will be created.  .  Then follow the instructions for adding MS-DOS to the Ghost boot wizard.  And, now you can elect to use one or the other version of DOS in creating a boot disk using the boot wizard.



Quote:

> Question Changing topic > this topic Since I started this thread, the subject line has never changed, although we're on several different *topics*. Is it possible to change the *subject line* WITHIN a  thread - WITHOUT *losing* the thread ? If so, why are we still working under: "Ghost 2003, Img XP > DVD, INCOMPLETE ??"

Yes, on each reply, you can go up to the *Re: Ghost 2003, Img XP > DVD, INCOMPLETE ??* line that is above the two formatting tool lines above the message editing box.--you can make the title whatever you wish.  The thread will not be lost!  (Note--I changed the title for my posting!)

But if you change the title, you might loose track of the thread because it will no longer appear on the main homepage with the original title--it will be listed by the *new* title.  But, if you look in the individual forum page, then the beginning title that you started with will still be the thread title--not the new title.

You can edit your postings for a limited time after posting (3 days)--so you could go back to your first post and change that title line.  But after the time limit, you then can no longer edit or change your posts.  But, any of the Moderators of the forum could edit it for you if there was a need to make a change.

@ NightOwl

"PC DOS 7 does not support FAT32"

"PC DOS 7.10

IBM produced PC DOS 7.10 which was based on PC DOS 2000 and added support for LBA and FAT32 partitions. This version of DOS was never released in retail but was used in several IBM products such as the IBM ServerGuide Scripting Toolkit. This version of DOS has also appeared in Norton Ghost from Symantec.Version 7.10 is returned to applications, since this is usually a test for support of FAT32."

My partitions/HDDs - internal & external are all NTFS.

I Have 1 (one) 8GB *usb flash drive* (stick) that's formatted in FAT32.

Is that the only reason why you recommend me to:

Quote:

add MS-DOS to the Ghost Boot Wizard--one of the wizard's pages has the option for doing this.  All you need is the floppy boot disk for Win98s OEM.  You can download it from here:  http://www.bootdisk.com/bootdisk.htm --just choose it from the list. ......

Did you mean Win98SE OEM ???
Typo  :-?

Since everything works fine with Ghost boot disks (floppies) - showing *PC-DOS 7.10* - the only reason I can think of is the possible use of FAT32 formatted flash drive(s). Correct ?

Then again, the floppies are FAT32 as well - how's that supposed to work (Ghost) ? ... Or is it because "Version 7.10 is returned to applications, since this is usually a test for support of FAT32." ?

---

I tried to find out what DOS version I really have - to no avail  :(

How can I find out what version I have, when I don't use Ghost floppies ?

---

Load of questions again ... I might not quite get the point ::)

henriette

   
 

@ henriette


Quote:

Did you mean Win98SEOEM ???

Yes--my bad!  I edited my previous post to correct that!


Quote:

My partitions/HDDs - internal & external are all NTFS. I Have 1 (one) 8GB *usb flash drive* (stick) that's formatted in FAT32. Is that the only reason why you recommend me to: Quote: [quote]add MS-DOS to the Ghost Boot Wizard--one of the wizard's pages has the option for doing this.  All you need is the floppy boot disk for Win98sOEM.  You can download it from here:  http://www.bootdisk.com/bootdisk.htm --just choose it from the list. ......

[/quote]
See how the topic of a thread *wonders*--there's always *another (sometimes *off topic*) question*   ;)  !

I did not mean for my post to say I'm recommending you use MS-DOS.  PC-DOS is perfectly fine (unless you have a particular hardware set up that is not compatible with PC-DOS--some hardware was made that needed specifically MS-DOS to function properly--but I have not seen any reports of that problem!).  I think I read somewhere in the Ghost 2003 User Guide that some systems may require MS-DOS, and that's why Ghost 2003 has the option to add it to the Ghost Wizard.  Symantec just did not want to pay the probably higher cost to license MS-DOS--for a problem that is probably very rare.


Quote:

I tried to find out what DOS version I really have - to no avail    How can I find out what version I have, when I don't use Ghost floppies ?

Not entirely sure what your asking--you said previously:


Quote:

My partitions/HDDs - internal & external are all NTFS

That means you are using NTFS based partitions to store files, and not FAT based partitions to store files!  Don't confuse file systems with OS's.  You are using WinXP OS when you boot to Windows--and that's not DOS!  You are only using DOS when you boot from the DOS floppies--which load DOS (Disk Operating System)--either MS-DOS or PC-DOS--or it could be DR-DOS or Free-DOS--there are a lot of different DOSs out there--as well as many different versions of a given flavor of DOS!

DOS can only see and work with FAT based file systems.  You will not be able to access any NFTS partitions or the files in them using DOS--no drive letters will be assigned to those.  Now, you can load a program like Ghost that has a built-in ability to see NTFS partitions and the files stored on those partitions--and Ghost 2003 can both read from and write to NTFS partitions.  There are also third party drivers that you can load along with the DOS boot files that are able to mount and show the NTFS partitions and files while you are in DOS--many of those are *read only* (free ones)--and that may allow you to copy them to other places.  In the past, only the expensive non-free DOS NTFS drivers could write to the NTFS partitions--there may be free ones now--I haven't looked in a long time.

You can also boot from a HDD that loads DOS from the HDD--it does not have to be DOS boot floppies--and you can load DOS from optical drives also if using a bootable disc.

Now, if you're asking what version of PC-DOS you have on your boot floppies, you can do the following:

In Windows open Notepad. 

Put your first boot floppy of the Ghost boot set in the floppy drive. 

In Notepad, use the *open* menu function--navigate to the A: drive--the list of files should include *IBMDOS.COM* and *IBMBIO.COM*--these are the IBM PC-DOS OS files that are loaded during boot.  Select one of them and that file will open in Notepad.

It will be a lot of gibberish for the most part--computer programing code that is not understood by this mortal man--I bet that Dan Goodell can figure out what it means--but, he's one of the *gods* and not a mere mortal  :) !

But, if you scroll down, you will often see readable text inside a file like these.  Here's what I found:


Quote:

IBMDOS.COM @#IBM:07.15.2002.build_1.19.Y2K,cdboot#@ IBMDOS.COM(USA) IBMBIO.COM @#IBM:07.15.2002.build_1.19.Y2K,cdboot#@ IBMBIO.COM(USA)

Sometimes, when booting to DOS--right at the very beginning (you have to watch closely or you may miss it), there will be a brief flash saying what version of the DOS OS is being loaded.  That message usually is coming from this text string that's inside the boot file like what's mentioned above.  But, not all DOS boot files show that information.

You can use Notepad to open all sorts of program files like the above PC-DOS boot files--and you will often find version numbers and other identifying information in plain text along with all that other gibberish data.

henriette wrote on Jun 23^rd, 2012 at 7:55am:

the floppies are FAT32 as well

Floppies are never FAT32.  They are always FAT12.  FAT12 was the original implementation of the FAT ("File Allocation Table") system, and was simply called "FAT".  It only supported up to a couple megabytes, though, so along came FAT16, which supported up to 2GB.  The terms "FAT" and "FAT16" differentiated the two file systems.  To break the 2GB barrier, along came FAT32.  Now, what used to be called "FAT16" is often referred to as simply "FAT", and the original "FAT" has become "FAT12".



Quote:

I tried to find out what DOS version I really have - to no avail. How can I find out what version I have, when I don't use Ghost floppies ?

Did you try the "ver" command at the command line?

@ NightOwl


Quote:

"Did you mean Win98SE OEM ???" Yes, I edited my previous post to correct that!

Thanks :=)


Quote:

PC-DOS is perfectly fine (unless you have a particular hardware set up that is not compatible with PC-DOS--some hardware was made that needed specifically MS-DOS to function properly--but I have not seen any reports of that problem!).  I think I read somewhere in the Ghost 2003 User Guide that some systems may require MS-DOS

Ghost runs fine as is  ;)


Quote:

you are using NTFS based partitions to store files, and not FAT based partitions to store files!  Don't confuse file systems with OS's. You are using WinXP OS when you boot to Windows--and that's not DOS!  You are only using DOS when you boot from the DOS floppies--which load DOS (Disk Operating System)--either MS-DOS or PC-DOS ...

AH !!! ~~~"I'm beginning to see the light"~~~


Quote:

DOS can only see and work with FAT based file systems.  You will not be able to access any NFTS partitions or the files in them using DOS--no drive letters will be assigned to those.  Now, you can load a program like Ghost that has a built-in ability to see NTFS partitions and the files stored on those partitions--and Ghost 2003 can both read from and write to NTFS partitions.

... like e.g. Ghost explorer --> extracting files ?


Quote:

you're asking what version of PC-DOS you have on your boot floppies

I did as told, here's what I found:


Quote:

*IBMDOS.COM*: @#IBM:07.15.2002.build_1.19.Y2K,cdboot#@ IBMDOS.COM(USA) *IBMBIO.COM*: JBéûý@#IBM:07.15.2002.build_1.19.Y2K,cdboot#@ IBMBIO.COM(USA)

Quote:

You can use Notepad to open all sorts of program files like the above PC-DOS boot files--and you will often find version numbers and other identifying information in plain text along with all that other gibberish data.

WOW! That's most amazing!
Your instruction on how to use the notepad knocked my socks off, NightOwl, ---> I'm *sockless*, so to speak  ;D

Thank you  [smiley=dankk2.gif]


@ Dan


Quote:

"the floppies are FAT32 as well" Floppies are never FAT32.  They are always FAT12 ... was simply called "FAT".  It only supported up to a couple megabytes ... To break the 2GB barrier, along came FAT32.  Now, what used to be called "FAT16" is often referred to as simply "FAT", and the original "FAT" has become "FAT12".

Yes, just recalled "FAT" (which I see when formatting  floppies), 1.44MB. Thanks a lot for explaining all detailed  [smiley=thumbup.gif]


Quote:

"How can I find out what version I have, when I don't use Ghost floppies ?" Did you try the "ver" command at the command line?

Once, yes, but in the *DOS box* - showed only the OS-version ::)

You mean booting to DOS, don't you ? ... just what kind of floppy or bootable CD should I take to accomplish that ?

henriette   :-?

@ henriette


henriette wrote on Jun 24^th, 2012 at 7:23am:

... like e.g. Ghost explorer --> extracting files ?

Not exactly--Ghost Explorer is a Windows only program--so it uses the Windows OS to access files--be they FAT or NTFS.


henriette wrote on Jun 24^th, 2012 at 7:23am:

You mean booting to DOS, don't you ? ... just what kind of floppy or bootable CD should I take to accomplish that ?

Yes, you need to use a DOS boot floppy, DOS bootable optical disc, DOS bootable flashdrive, or DOS installed on your HDD for booting from--just has to be boot media that gets you to a DOS prompt (not a Windows *command* window--which gives you this response:


Quote:

C:\>ver Microsoft Windows XP [Version 5.1.2600]

).

Then type:  *ver* at the real DOS prompt.

henriette wrote on Jun 24^th, 2012 at 7:23am:

re: "Did you try the "ver" command at the command line?" Once, yes, but in the *DOS box* - showed only the OS-version

Of course it did.  A "DOS-box" is not DOS.  It's an emulator running in Windows, so the "ver" command is naturally going to show the Windows version.



Quote:

You mean booting to DOS, don't you ? ... just what kind of floppy or bootable CD should I take to accomplish that ?

Any DOS-bootable floppy, CD, or flash drive.  Understand that the DOS operating system is installed on the device you are booting from.  For instance, if you boot from a bootable CD, the "ver" command will reveal the version of DOS installed on the CD.  If you boot from a Ghost boot floppy, "ver" will reveal the version of DOS on the Ghost floppy.  It's unlikely your hard drive has DOS installed on it anywhere, but if it did you wouldn't know what version it is unless you boot from the hard drive to DOS.

Of course, not any floppy, CD, or flash drive is bootable.  You have to choose to alter it and make it bootable.  If you choose to do so, you also have to choose what OS to make it boot.  The most common OS's to put on a bootable floppy, CD or flash drive are some version of DOS, linux, or WinPE.

@ NightOwl


Quote:

Ghost Explorer is a Windows only program--so it uses the Windows OS to access files

Oh yeah, that's right! I'm afraid it'll take some time for me to differentiate between OS and DOS ... as you said:


Quote:

Don't confuse file systems with OS's. You are using WinXP OS when you boot to Windows--and that's not DOS!  You are only using DOS when you boot from the DOS floppies--which load DOS (Disk Operating System)

Quote:

"what kind of floppy or bootable CD should I take to accomplish that ?"

Quote:

you need to use a DOS boot floppy, DOS bootable optical disc, DOS bootable flashdrive, or DOS installed on your HDD for booting from--just has to be boot media that gets you to a DOS prompt - Then type:  *ver* at the real DOS prompt.

Will do so  ;)

@ Dan


Quote:

A "DOS-box" is not DOS.  It's an emulator running in Windows, so the "ver" command is naturally going to show the Windows version.

Quote:

Understand that the DOS operating system is installed on the device you are booting from.  For instance, if you boot from a bootable CD, the "ver" command will reveal the version of DOS installed on the CD.  If you boot from a Ghost boot floppy, "ver" will reveal the version of DOS on the Ghost floppy.  It's unlikely your hard drive has DOS installed on it anywhere, but if it did you wouldn't know what version it is unless you boot from the hard drive to DOS.

Well, well, well,,,,, I've been that naive to think that there's 1 (one) version of DOS on my computer. Dang  ;D

Now I read all the different versions °in combination° with different boot media. Wow!
---> a new area has begun .. for me, and with the excellent help/lessons from both of you, there may be a good chance for me to understand it - little by little. ...

henriette  [smiley=thumbup.gif] [smiley=thumbup.gif]

@ henriette


Quote:

I'm afraid it'll take some time for me to differentiate between OS and DOS ...

Just to be clear...DOS is an OS!  DOS only can work with FAT file systems (FAT12, FAT16, FAT32) unless you load a driver or program that can access NTFS file system partitions.