-=PCTechTalk=- Re: Outlook Express Question

  • From: GMan <gman.pctt@xxxxxxxxx>
  • To: <pctechtalk@xxxxxxxxxxxxx>
  • Date: Fri, 16 Nov 2007 22:50:18 -0500

See my interjections below.

Peace,
GMan

"The only dumb questions are the ones we fail to ask!"

----- Original Message ----- 
From: "DSWabc" <dswabc@xxxxxxxxx>
To: <pctechtalk@xxxxxxxxxxxxx>
Sent: Friday, November 16, 2007 1:04 AM
Subject: -=PCTechTalk=- Re: Outlook Express Question


> Sorry to disappoint you but there was nothing to hate in your reply.  :-))
>

Actually, I started out my reply going in a different direction than what 
you eventually got to read.  I ended up hating the first draft, so it was 
scrapped in favor of the one you did see.           lol


> I used a bad phrase... when I said "lasts a little while and then goes
> away", I meant that the correct condition(s) exist long enough to cause 
> the
> problem to a few messages and then the condition(s) stop existing and no
> further damage is done.  Until next time.

Yes, I misunderstood you (or your wording threw me off).  Either way, this 
is exactly the experience I have had on at least 3 occasions.  I do not 
believe it happened during an OE session, however.  It revealed itself after 
firing up the app and trying to reply to certain posts.  I cannot be sure if 
any of those posts had just come in diring that particular session, but I do 
know that it occured with messages that were downloaded during a previous 
session.

>  Has there been a next time?

As I mentioned above, this has happened to me at least 3 times over a 6 or 7 
year period and spanning different major OE versions (not exactly sure which 
of 3.x, 4.x, 5.x & 6.x).

>  I
> did not mean to imply that the bad messages became good a few days later.
> Sorry for the confusion.
>
> This is going back to the late 80s and my time spent playing with dBase 
> II,
> III and IV (mostly II and III) and refers to the paragraph where you 
> discuss
> data fragmentation within the dbx file.  It includes some elementary info
> that you probably already know to help others understand database files.
>
> A database file consists of one or more records.  In our case a message is 
> a
> record.  Each part of the message is a data field within the record.  I do
> not know how OE separates the message into the separate data fields.  It
> might not and the record may consist of only one data field.  (I'd love to
> find a utility or database program that would let me explore an OE dbx 
> file)

I have used several things to look inside these files.  If you have a small 
one with only a few messages in it, just open it up with WordPad to see the 
actual byte structure.  You'll see that it is set up differently than your 
description of standard databases below.  Unfortunately, I am unaware of any 
that will parse the entries into various data fields, although such a beast 
may, in fact, exist.

>
> When the first record is added to the file it is at the top of the file
> (tof).  If it is the only record it is also the end of the file (eof).
>
> Each time a record is added, it is appended to the end of the file.  Each
> time a record is deleted it is not really deleted.  It is simply marked 
> for
> deletion.  So the record is still intact within the file.  That means 
> there
> is no empty space to write a part of a record to and then finish it in
> another empty space somewhere.  In other words, records within the file do
> not become fragmented like the file itself could be on the hard drive
> surface.  Thus there is no need for the dbx file to maintain an index.

This idea deserves testing, but I do not have the time to conduct it 
tonight.

>
> Actual deletion happens when the file is compacted.  At that time the
> records marked for deletion are removed and the remaining records 
> re-written
> to the file as we discussed in a previous message.
>
> I also wish you could remember which messages had this problem.  It would
> indeed be fun to experiment with moving messages into different folders 
> and
> maybe back again oe even through a series of folders and end in the 
> deleted
> file.  It would also be interesting to see if there was any commonality
> amongst the affected messages such as I suggested in an earlier message.
> What if you forwarded the message to someone as an attachment, it was
> replied to and then you replied again.
>
> I am going to try to write a brief desciption of this problem and post it 
> to
> an OE newsgroup at MSnews.  Maybe they know something we don't?

Let me know if you receive anything new back from them.        :O)

>
> Don
>
>
>
> ----- Original Message ----- 
> From: "GMan" <gman.pctt@xxxxxxxxx>
> To: <pctechtalk@xxxxxxxxxxxxx>
> Sent: Thursday, November 15, 2007 4:45 PM
> Subject: -=PCTechTalk=- Re: Outlook Express Question
>
>
>> To anyone trying to follow along:  There is a LOT of tech-speak in this
>> one.
>> If it seems like we're talking in circles or that little of it seems to
>> make
>> sense, don't be alarmed.  It's not you.  We're just bouncing ideas off of
>> each other in an effort to get to the bottom of the issue.  On the other
>> hand, if you're able to follow the ideas and they make sense, it means
>> that
>> you've stepped over the line and now need to consider that idea that
>> you've
>> inadvertently become a power user.      hehe
>>
>>
>> Hi Don,
>>    You're probably going to hate this reply, but at least you can put the
>> first aid kit away.  Simply put, I am not a programmer, either.  Two
>> semesters of FORTRAN back in '82-'83 doesn't qualify me enough to find 
>> the
>> logic in this problem.  Still, I will do my best to support/refute your
>> reply.
>>
>>    I have absolutely no suspicions of a drive problem here.  The purpose
>> of
>> running CHKDSK in this case is just to make sure the data I'm about to
>> compact is as intact as possible.  If the 'reply addy' issue happens to 
>> be
>> stored in a spot on the drive's platters that's questionable, I have
>> little
>> hope that compacting the affected folder will teach me anything.  In 
>> other
>> words, I just want to scrub in before conducting any surgery.      :O)
>>
>>    In my case, the reply to addy was NOT changed to the default.  On the
>> contrary, the default happens to be the one that it was supposed to use.
>> Not specifically because it was the default addy, but because the default
>> addy happened to be the one I use for that group.  This issue changed the
>> 'reply to' addy to the addy I had most recently added to my email
>> accounts.
>> This kinda knocked out most of the relevance to the link you sent.
>>
>>    I'll also mention here that the problem doesn't necessarily 'go away'
>> after some time.  As far as I know, the messages in my PCTT folder that I
>> mentioned in my previous reply are still affected.  It's just that I have
>> had no reason to revisit those threads and reply to any of them
>> (significantly taking the issue out of the way).  Since they are not in
>> the
>> way of my future progress and my focus is always on helping folks in the
>> present & teaching for the future, they were easily forgotten.
>>
>>
>>    Here's the part where my own limited knowledge of programming makes me
>> look smart enough to answer a simple question or two, but dangerous 
>> enough
>> to send me off on tangents that may or may not produce anything useful 
>> (at
>> least to others).  Please be aware that nothing here is meant as a
>> rebuttal
>> or confirmation of what you've said.  I am simply thinking out loud (with
>> smoke pouring out of my ears).     lol
>>
>>    I'm not thinking that the same exact small isolated part of multiple
>> consecutive messages has become slightly corrupted enough to only affect
>> the
>> 'reply to' control.  There is no logical sense in that line of thinking
>> and
>> your reply helps to confirm that for me.  I am also 100% sure that DBX
>> files
>> do not separate different lines of headers so that line 1's, 2's, 3's,
>> etc.
>> are written next to each other.  Like any other simple database, a single
>> entry should be represented in its entirety without interruption.  The
>> only
>> thing that throws that off is the subsequent removal of entries which, of
>> course, leads to data fragmentation within that DBX file.  The more often
>> the DBX file is compacted, the less often this should occur.  Still, OE
>> normally has no problem getting around the file to collect the data 
>> needed
>> to display any given message saved in them.  Since OE obviously has to
>> work
>> with a process that handles DBX file fragmentation, I have to assume that
>> there is some sort of data table or index (similar to a hard drive's FAT)
>> at
>> the head of each DBX file that tells OE where to find the various parts 
>> of
>> a
>> given message.  Assuming that's true, compacting, which rearranges the
>> data
>> and restructures this index, just might do something to help fix the
>> issue.
>> Again, I'm not saying that I expect it to work.  It's only meant as an
>> experiment.  Oh, and yes, compacting a DBX file causes a replacing of the
>> entire file, exactly as you described it.  It's very similar to when you
>> defrag a hard drive, except that a hard drive defrag writes the parts
>> directly back to the drive instead of using a temp file.
>>
>>    Just prior to the break in your reply (where you said "... hours
>> later"), you provide three ideas.  The third possibility is the only one
>> that has kept with me over the years.  The reason for that is that the
>> 'reply to' process may not be fully contained within OE &/or its support
>> files.  What if the process starts there, but then consults a switch or
>> other mechanism within each DBX file's index?
>>
>>    I am now also wondering if moving an affected post to a different OE
>> folder (and therefore a different DBX file) would change anything.  It
>> would
>> have a similar effect as what I'm looking for in compacting the DBX file,
>> but use a different mechanism.  OE would still have to consult the index
>> to
>> locate all parts of the post, but it wouldn't necessarily have the means
>> to
>> repair anything it found that perhaps wasn't kosher.  It's at this point
>> that I really wish I knew which of my old posts were the affected ones so
>> I
>> could see if they were still affected and perhaps test some of these
>> blasted
>> thoughts.        lol
>>
>> Peace,
>> GMan
>>
>> "The only dumb questions are the ones we fail to ask!"
>>
>> ----- Original Message ----- 
>> From: "DSWabc" <dswabc@xxxxxxxxx>
>> To: <pctechtalk@xxxxxxxxxxxxx>
>> Sent: Thursday, November 15, 2007 11:51 AM
>> Subject: -=PCTechTalk=- Re: Outlook Express Question
>>
>>
>>> Just some thoughts.  Please feel free to punch holes in them.  My lack 
>>> of
>>> programming skills is STILL not helping so I expect to bleed at least a
>>> little bit from the punches.  :-))
>>>
>>> If the disk surface has a bad spot or a series of bad spots that cause 
>>> OE
>>> to
>>> read data incorrectly it seems unlikely to me that the bad space(s) 
>>> would
>>> be
>>> so perfectly located as to impact only the "use this account to send
>>> from"
>>> address (and nothing else) and only in consecutive messages.  Especially
>>> since the file is very likely fragmented and message one is here and
>>> message
>>> two may be  way over there.  It would be more likely if the dbx file is
>>> structured such that line 1 of the headers of all messages are placed
>>> first,
>>> then line 2, 3 and so on.  That seems unlikely though since some headers
>>> are
>>> very short and some are very long and I think a structure such as that
>>> would
>>> require a relational database rather than a standard database and would
>>> seriously slow down the process of displaying the message.
>>>
>>> If the dbx file itself is corrupted, it would also seem unlikely that 
>>> the
>>> points of corruption would be as perfectly placed as described above.
>>>
>>> If either of these situations existed I would think that consecutive 
>>> data
>>> within a specific message or a series of entire messages would be having
>>> problems. For example it would start at a random point in a given 
>>> message
>>> and stop at a random point in another message and the messages impacted
>>> may
>>> or may not be consecutive depending on the degree of file fragmentation.
>>>
>>> Also, how would corruption that impacts a specific folder in a specific
>>> account pull up an entirely different account's email address when there
>>> is
>>> no reference to that address in the message headers?   Unless, two
>>> different
>>> message folders are corrupted and data was switched between them.  But
>>> wouldn't that put the incorrect data in the headers?  And cause problems
>>> in
>>> both folders?  Or could the corruption tell OE to look in one
>>> message/folder
>>> for the message being replied to but look in a different message/folder
>>> (or
>>> to a different account) to determine the account to send the reply from?
>>>
>>> From watching OE compact folders on my system it appears that the 
>>> process
>>> simply reads the records (messages) that have not been marked for
>>> deletion
>>> into a temp file or buffer of some sort then deletes the file and
>>> re-writes
>>> the stored records back to a file with the same name.
>>>
>>> Compacting the folder, might fix the problem by changing the dbx file
>>> size
>>> and relocating the affected messages away from a bad spot on the drive.
>>> It
>>> might also just move the problem to a different series of messages in 
>>> the
>>> same folder.   I don't think it could actually repair any corruption in
>>> the
>>> data stored in the records though it might fix any damage in the 
>>> physical
>>> structure of the dbx file since it is in fact creating a new file for 
>>> the
>>> data.
>>>
>>> If my thinking has any basis to it, what is left to look at is (in no
>>> particular order or priority):
>>>
>>> --Human error ( though I can't think of what it might be)
>>> --An address book in somebody's email client
>>> --Corruption in the process that selects the account to send a message
>>> from.
>>> If this is the case why is it only one folder and a select few
>>> consecutive
>>> messages and only lasts a little while then goes away?
>>>
>>> <couple of hours later...>
>>>
>>> I just found this article at Tom Koch's site but it appears to be 
>>> limited
>>> to
>>> News accounts and also to be fixed with SP2.  But it still might be
>>> relevant
>>> to this problem.  After reading it, I suspect something is causing OE to
>>> lose track of which account to use and automatically defaults to the
>>> default
>>> account.
>>>
>>> http://www.insideoe.com/problems/bugs.htm#acctwatch
>>>
>>> if broken, try: http://tinyurl.com/z5rvj
>>>
>>> Don (with gauze pads and bandages waiting)
>>
>
>
> ---------------------------------------------------------------
> Please remember to trim your replies (including this sentence and 
> everything below it) and adjust the subject line as necessary.
>
> To unsubscribe or change your email settings:
> //www.freelists.org/webpage/pctechtalk
>
> To access our Archives:
> http://groups.yahoo.com/group/PCTechTalk/messages/
> //www.freelists.org/archives/pctechtalk/
>
> To contact only the PCTT Mod Squad, write to:
> pctechtalk-moderators@xxxxxxxxxxxxx
> ---------------------------------------------------------------
> 


---------------------------------------------------------------
Please remember to trim your replies (including this sentence and everything 
below it) and adjust the subject line as necessary.

To unsubscribe or change your email settings:
//www.freelists.org/webpage/pctechtalk

To access our Archives:
http://groups.yahoo.com/group/PCTechTalk/messages/
//www.freelists.org/archives/pctechtalk/

To contact only the PCTT Mod Squad, write to:
pctechtalk-moderators@xxxxxxxxxxxxx
---------------------------------------------------------------

Other related posts: