XCLN: How the Exchange Windows 95 Client Uses Control.glb

Last reviewed: April 2, 1997
Article ID: Q148515
The information in this article applies to:
  • Microsoft Exchange, version 4.0
  • Microsoft Mail for PC Networks, version 3.2, 3.5.

SUMMARY

When you use the Microsoft Exchange client for Windows 95 to communicate with a Microsoft Mail 3.x postoffice, Control.glb is not incremented after every message sent.

MORE INFORMATION

Control.glb is an eight byte file. The first four bytes are used to store a hex number that is used to create the unique file prefix used to name all the database files that are unique to the new user. The second four bytes are used to store a hex number that is used to generate names for new messages and attachments as the are created and written to the Postoffice.

The Microsoft Exchange client for Windows 95 performs a caching function that opens Control.glb, retrieves five hex-id's, and then increments Control.glb accordinly. The client then caches the extra hex-ids anticipating that the user will send more mail during the session. This process reduces the number of times that the Microsoft Exchange client for Windows 95 must access Control.glb, thus reducing the possibility of file contention problems. This process does not expose the mail database to corruption, however, this will affect utilities such as Traffic.exe that use the Control.glb counter as a method of tracking the number of messages and attachments processed by that postoffice.

The Microsoft Exchange client for Windows 95 also automatically creates an attachment for every mail message sent in Rich Text Format (RTF). This is a hidden attachment named Winmail.dat that contains the information needed to display RTF on another Microsoft Exchange client. Because of this, the Microsoft Exchange client for Windows 95 will use at least two Control.glb numbers for each mail message sent; one for the message and one for Winmail.dat. Each additional attachment uses another distinct Control.glb number.

When a message with an attachment is sent, the attachment is created and stored in the appropriate ATT subdirectory. File names for attachments, or ATT's, are made up of an 8-digit hex number created from the right 4 bytes of Control.glb and followed by an AT(#) suffix. For example, 00001b45.att is an attachment and is stored in the \ATT\AT5 directory. Federal Information Processing Standard (FIPS) format dictates that the attachments are owned by the messages. Since the attachment, .ATT, was created first, the hex-id of the ATT is stored as a field in the message. If there are many attachments, each hex-id uniquely generated by Control.glb is stored in the message. The mail message itself follows the same naming and storage conventions as attachments.


Additional query words:
Keywords : kbusage XCLN
Version : 4.0 5.0
Platform : WINDOWS


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: April 2, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.