Brian

Quote:

Probably true--I just like being a *drama king*  !

Brian wrote on Nov 28^th, 2010 at 3:18am:


Ah, found their (TeraByte) help page for setting up Outlook Express:  Set Up Help for Outlook Express

NightOwl

NightOwl wrote on Nov 28^th, 2010 at 3:34am:

I haven't had to think about that yet and I don't think Outlook does newsgroups. Let me know what you find.

NightOwl wrote on Nov 28^th, 2010 at 3:34am:

I use Xnews.  I like it particularly because it's "no install".  I put it on a flash drive, and no matter whose computer I'm using, I can launch it from my flash drive.  It's only for newsgroups, not regular email.

Thunderbird is an excellent email replacement for Outlook Express, and also happens to do newsgroups.  There's even a portable version, which is what I use for all my email these days.

Dan Goodell

Quote:

Thanks for the recommendation--I'll give it a try!

Okay, having had a chance to study the PartInfo reports in this thread, I can see several problems.  The problems fall broadly into two areas: corrupted CHS values in partition descriptors, and improperly calculated LBA values in descriptors in the extended partition.  Since we have a couple of newcomers, it’s probably worthwhile to include a review of some history and principles.

Back in the 1980’s and 90’s, sectors on a hard disk were identified by their geometrical coordinates—that is, the Cylinder, track (aka, “Head”), and Sector position on the track.  In the partition tables, a descriptor defined a partition by its starting and ending C, H, and S coordinates.  The C, H, and S fields in the descriptor could accommodate values of 0-1023, 0-254, and 1-63, respectively.  Partitions were always divided along cylinder boundaries, except when it was preceded by a partition table, in which case the starting point was offset by one track.  Thus, partitions always began on Sector 1 of Head 0 or 1 on a particular Cylinder, and always ended on Sector 63 of Head 254 on some other Cylinder.

The CHS method worked for hard disks up to about 8 GB in size.  Larger disks would require cylinder values above 1023.  To accommodate larger disks, LBA references were added to the partition descriptors.  LBA eschews geometry altogether and counts sectors as one long, continuous string, from the beginning of the hard disk to the last sector on the disk.

Descriptors still retained CHS values for backward compatibility.  Thus, in addition to the boot flag and file-system type identifier, the 16-byte descriptor for a partition specifies the partition’s beginning location in CHS terms, ending location in CHS terms, the beginning location in LBA terms, and the number of sectors in the partition.  (Note the LBA ending point can be derived from the LBA starting point plus the volume size in sectors.)

Okay, here’s the catch.  While a location within the first 8 GB of the disk can be referenced by either its CHS or LBA coordinates, beyond that you must use LBA.  In that event, the C register is supposed to be “pegged” at 1023, its maximum value.  1023 is a useful alert that you’re supposed to get the real sector location from the LBA field instead.  Unfortunately, some partitioning tools—most notably, linux-based utilities—don’t freeze the value and let the C counter rollover to start counting up from zero again.  The PartInfo report in Reply #3 illustrates this anomaly.  The last partition, for example, really spans CHS 14793/1/1 to 19456/254/63.  However, instead of pegging the Beginning C-counter at 1023, it was allowed to rollover 14 times and count up to 457 for a 15th time (14793 – 14*1024 = 457).  Similarly, the Ending C-counter rolled over 19 times and was just beginning its 20th cycle (19456 – 19*1024 = 0).  While the BCHS and ECHS values should have been 1023/1/1 and 1023/254/63, they are shown as 457/1/1 and 0/254/63.

So, is this a problem?  Well, that depends on who’s trying to interpret the partition descriptor.  Linux apparently has no trouble and just looks at the LBA value.  For the most part, Windows also seems to get it right (at least, most of the time).  But other tools that are not so carefully designed can interpret a C value of other than 1023 as definitive, and could end up reading and writing to Cylinder 457 instead of Cylinder 14793—with drastic consequences!

You’ll notice a lot of corrupted BCHS and ECHS numbers in the Reply #3 PartInfo report and the Reply #15 PartInfo.  There are even a few in the Reply #12 PartInfo (all those 1022’s should be 1023).  As mentioned above, this isn't necessary a problem until you try to use a tool (like Partition Magic, for example) that looks at the CHS numbers.

(Aside: Reply #15 illustrates an unrelated side issue--Thinkpad, Compaq, and certain HP laptops have long used a maximum H value of 239 instead of the more common 254.)


continued...

xcurious

Quote:

That's good!  Didn't exactly solve the original problem--but sounds functional for you!

Quote:

Well, I suppose that could be argued--but DL258's issue is very similar in nature--if you read the information that Dan Goodell has mentioned--you both lost partitions being listed in the Windows Ghost interface--and the *cause* seems to be corrupted partition table information.

You mentioned that you used some alternate imaging tools in the last month, or so--that might have contributed to changed partition table structure--but DL258 has stated that he's done nothing of that kind--used only his Vcom partitioning tool and Ghost 10 and Ghost 2003!  The two of you should be comparing notes to see if there's any commonality in anything you have done recently--or in the past!

Quote:

I think Brian was actually responding (belatedly) to your replies #3 and #4--I think he had waited, hoping Dan Goodell might respond sooner--no way to know he was on holiday.

NightOwl wrote on Dec 1^st, 2010 at 12:01am:

I wouldn't jump to the conclusion that it's "usually" a linux based tool.  IME, other tools have created the same rollover effect.

Those with some experience in binary arithmetic will recognize this rollover effect is a natural occurrence.  Remember that computers work in binary, so in my previous example from Reply #12, the Cylinder number of 14793 (decimal) is 0011100111001001 in binary.  Note that 457 (decimal) is 0111001001 in binary.  The Cylinder fields in the partition descriptor are 10-bit numbers, so if you mask out the high-order bits in the decimal number 14793 and take only the low-order 10 bits, you end up putting 457 in the partition descriptor.

If you're not diligent, you end up with that natural rollover.  To do it properly, a program should mask out the low-order 10 bits and look at the high-order bits.  If there is any non-zero bit left, discard all low-order bits and substitute 1111111111 binary (1023 decimal) for the Cylinder field's 10 bits.

As you can see, inattentive programming yields natural rollover, while freezing the number is the method that requires extra steps.  Thus, we should expect there to be more than a few third-party tools that exhibit similar rollover behavior.  I frequently see rollover with linux utilities (like GParted, for example), but have also seen it in cases where the user insists they have never touched linux.

The more critical error, though, is the miscalculated extended partition descriptors.  I don't recall seeing that before.  (I examine lots of partition tables, but the majority don't include extended partitions.)  All the numbers add up perfectly (or perfectly wrong, as it were), so it's not an unintended bug in the program--some programmer consistently coded the app to perform the wrong calculation.  I haven't done a survey to see if there's any correlation here with linux tools or not, so I wouldn't want to jump to conclusions.

I've mentioned this before but not yet in this thread, that I've long held that installing Ghost 2003 and running it from Windows is extremely foolish.  Ghost 2003 is a DOS program and is reliable when used from a DOS boot, but running it from Windows is known to cause problems.  If I read correctly, both xcurious and DL258 noticed problems after installing Ghost 2003 in Windows, so I wouldn't rule out the possibility it's the Windows front end that's causing these problems.  It would take some work, but one way to tell for sure might be if xcurious and/or DL258 reconstructed their partition structure before Ghost 2003 was installed, then installed Ghost 2003 in Windows, and then captured PartInfo reports before and after running Ghost 2003 from Windows for the first time.