-=PCTechTalk=- Re: Outlook Express Question
- From: "DSWabc" <dswabc@xxxxxxxxx>
- To: <pctechtalk@xxxxxxxxxxxxx>
- Date: Fri, 16 Nov 2007 01:04:02 -0500
Sorry to disappoint you but there was nothing to hate in your reply. :-))
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. Has there been a next time? 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)
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.
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?
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
---------------------------------------------------------------
Other related posts:
