Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mail returns from being deleted and turns to "unread"

Status
Not open for further replies.

CharlieIT

MIS
Apr 9, 2003
157
US
I have a client who is using Lotus Notes 5.0.8 on a Windows 2000 SP4 workstation.

He gets A LOT of mail.

He says that he read over 200 e-mail messages today and they have suddenly changed from black (read) to red (unread). He also claims that a number of e-mails he deleted have since returned. He says he did nothing to initiate this (no key strokes, pull down choices, etc.).

Does anyone know what is happening and maybe have some suggestions on how to fix it?

Thanks!
 
Correction: I checked his computer again this morning, and he is replicating his mail locally. Could this be causing the problem? If so, How would I fix this?
 
Read and Unread marks are a rather complicated issue within Notes. Please find attached a Technical Paper from Lotus Customer Support: 'The Architecture of Unread Marks in Lotus Notes' where the handling of unread marks is explained in detail for different scenarios.

Hope this helps. :)


  Customer Support   Technical Paper
Title: The Architecture of Unread Marks in Lotus Notes
Product Area: Notes
Product: Notes 4.x, Notes Client 4.6x, Notes Client 4.5x, Notes 4.1x
Topic: Workstation/Desktop \\ Notes Client Functionality
Number: 172075
Date: 04/27/2000




In every database, Lotus Notes keeps track of each document that every user has read. This information is stored and maintained by several structures within both the .NSF and the Notes client itself. The following is a description of this architecture.

The Unread ID Table

In Notes R4.x, each database stores the list of unread documents in an Unread ID Table within the NSF file. To save space, this table stores a list of Note IDs instead of the longer UNIDs. Because of this, the table is specific to the replica that stores it.

This table is user-specific and is stored within the .NSF file in a special structure named with the hierarchical user name to which it applies. When a database is opened, this table is transferred locally to the Notes client and stored temporarily in the DESKTOP.DSK file. All updates to the table are then performed locally during the session for which the database is opened. It is important to recognize that there is no date information regarding when a particular document is marked read, aside from the time stamp of the ID table itself. Therefore, conflicts between replicas are not resolved in a similar way to replication conflicts. It should also be noted that because these tables are lists of Note IDs, any synchronization between tables must involve the conversion of Note IDs to UNIDs.

While the Notes user is accessing a database, all read operations are logged in a structure called the Unread Journal. This Journal is stored in the client's CACHE.DSK file and stores about 20,000 consecutive operations in a circular data structure (FIFO) that tracks all of the UNIDs of documents marked read or unread while accessing a database. This Journal is specific to the Notes client and is not involved with tracking any operations performed by an API program such as Organizer 97 GS. In addition, when a user marks all documents in a database 'read,' only the current set of documents is affected, so new documents must still be tracked properly. Therefore, a 'Mark All' operation is really a set of individual operations, one for each document. Because of the Journal limit, Notes limits these types of operations to 1,000 documents. In cases where there are more documents affected, Notes stores a 'Mark All Before this Time' operation in the journal. Obviously, if the times are off between servers or if this action is performed upon a partial replica, this could cause inconsistent behavior.

How are Unread Marks Updated?
The Unread ID table is updated in a few different ways, most often as users open or edit documents. The Unread ID table is transferred locally to the DESKTOP.DSK file and updated there. When the user closes the database, the ID table is transferred back to the .NSF file. This is true regardless of whether the database is residing on a server. Users see the unread marks in views that utilize the property to display them. The Unread ID table is overlaid onto the view index, and the client is then responsible for displaying the entries properly. When a user chooses to update the read/unread status of a document using the menu, the same behavior is followed.

How are Unread Marks Maintained?

Here we will investigate four different situations involving Notes clients and Notes database replicas.

Single client - Single replica
The Unread ID table is transferred to the local DESKTOP.DSK as a user opens the database. The Unread Journal in the CACHE.DSK is then "played back" against this ID table and the table is updated to reflect any changes that the Journal has logged. The modified Unread ID table is then transferred back to the .NSF file when the database is closed. In these situations, the net result is that the Unread Journal does little more than track the user's actions. The Journal does not really come into play until multiple replicas are introduced.

Multiple client - Single replica
This is similar to the above situation, except two DESKTOP.DSK files are being used. As long as each client is closing the database before it is opened by the other, the Unread Table should be maintained correctly. However, if the two clients are accessing the same replica simultaneously, problems may arise. If each client is maintaining a local copy of the Unread ID table, then the "last one out" principle is observed. Whichever client is the last to close the database will overwrite the entire Unread ID table maintained by the other client.

In R4, this is a situation that can also be caused by other API programs running on the same machine, such as Organizer 97 GS. Each program maintains its own Unread ID table, and inconsistencies appear because the two programs rarely touch the same documents. This can be mitigated by using the NOTES.INI parameter, NSF_UNREAD_METHOD=1, which allows the API programs (Notes included) to modify only the document entries that it touches. Changes to the R5 architecture take care of this limitation and the parameter is no longer required.

Single client - Multiple replica
Again, the Unread ID table is transferred to the local DESKTOP.DSK file. In this case however, the Unread Journal comes into play. Once the Unread ID table is local, the Unread Journal is "played back" against the table, updating it with the operations performed in the other replica. The limits outlined above will affect the performance of this scenario. Alternatively, the user may select two replica icons from the workspace and manually exchange unread marks. This can be performed either by using the menu command Edit, Unread Marks, Exchange Unread Marks, or by using a SmartIcon that performs @Command([ExchangeUnreadMarks]). These actions would have to be performed while icons are unstacked on the workspace. Note that the while the @Command still exists in R5, the menu command does not.

Multiple clients - Multiple replicas
This situation most likely will result in inconsistent unread mark lists. It is also fairly common. Stepping through the processes that are outlined above, it is clear that the structures and methods in place for maintaining unread marks are not sufficient for this situation. If two clients are exclusively accessing two separate replicas, neither the Unread Mark ID table nor the Unread Journal will be able to synchronize unread marks between the two replicas. Replication on its own does not synchronize unread marks either. Because the Unread Mark ID tables are user-specific and use Note IDs, it is not feasible to transfer all of these tables during replication.

To accommodate this type of situation, the Notes client implements an .INI parameter, REPLICATOR_SYNC_UNREAD. This parameter should equal the number of half-hours between Unread ID table synchronization. It is a client implementation only, and will not synchronize unread marks between servers unless a client is initiating the replication event. Even in this case, the only Unread ID tables that will be updated will be the ones specific to the user initiating replication. The intention of this parameter is to help synchronize the Unread ID tables between two replicas that are primarily used by different clients. An example of this would be an office replica that resides on a server and a remote replica that resides on a home machine or a laptop.

This parameter works by synchronizing the Unread ID tables of the two replicas after each replication event that comes after the minimum number of half-hours specified in the .INI file. For example, if the .INI file has REPLICATOR_SYNC_UNREAD=2, the replicator will synchronize the Unread ID tables once an hour. If replication occurs as a background process every fifteen minutes, synchronization will occur only every fourth replication event. If this parameter is set to -1, the replicator will synchronize the Unread ID tables after each replication event. For more information on this parameter, refer to the document titled, "Unread Marks Are Not Exchanged Replicating to a Server From Two Different Clients" (#158903 ).

It should be noted that this will have a negative affect on replication times. In addition, this feature may be made obsolete or implemented differently in future versions of Notes. Another caveat that should be included here is that there are no replication conflicts in this process. These ID tables may have conflicting information in them regarding a single document. Because documents generally go from 'unread' to 'read,' these conflicts are always resolved to 'read.' This might not be what the user expected. The Unread Journal does not have this same problem because while it does not track the exact times of the operations it tracks, it does know in what order they occurred.

In Release 5.0, this Unread Mark Architecture is not drastically altered. Most of the changes to this process were to internal code while leaving the main procedures intact. The most significant new feature is a database property that prevents unread marks from being maintained completely. Because of the network traffic that is necessary to track and update the Unread ID tables, this feature should provide increased performance for databases that implement it.


Related Documents:

Unread Marks Are Not Exchanged Replicating to a Server From Two Different Clients
Document #: 158903

Are Unread Marks Fixed in Release 5?
Document #: 169936
 
I have forgotten something: please find below a knowledge collection of different problems regarding read and unread marks in Notes. If you want to habe a look at the different Technotes just go to the IBM web-site and search for the Technote-Number.

Customer Support   Technical Paper
Title: Knowledge Collection: Read and Unread Marks in Notes/Domino
Product Area: Domino Server, Notes
Product: Domino Server 5.x, Domino Server 4.6x, Domino Server 4.5x, Notes Client 5.x, Notes 4.x
Topic: Messaging & Mail \\ Workstation Mail (Mailer) \\ Wkstn Based Mail Issues
Number: 185067
Date: 04/11/2001



Read and Unread Marks in Notes/Domino

DEFINITION OF A KNOWLEDGE COLLECTION:

THE COLLECTION:
General Information

The Architecture of Unread Marks in Lotus Notes
Document #: 172075

How Do Unread Marks Work in a Notes/Domino 4.x Environment?
Document #: 160731

Are Unread Marks Fixed in Release 5?
Document #: 169936

The Unread Mark Status for a Document Is Incorrect in Release 5
Document #: 179656


Troubleshooting Specific Issues

R5: Two Common Unread Mark Scenarios: New Mail Appears Read & Already Opened Mail Appears Unread
Document #: 179683

R5: New Mail Appears as Already Read When Deletion Stubs Are Purged from a Mailfile on Domino Server
Document #: 180164

R5: New Mail Appears as Already Read When Compact Is Run on an R4.6 (ODS 20) Database
Document #: 180570

Unread Marks Are Not Exchanged During Replication
Document #: 158903

New Mail Appears as Read After Dragging a Document to a Folder
Document #: 156170

Previously Read Mail Is Marked Unread in Notes
Document #: 178582

In Notes 4.x, the Read or Unread Status for a Document Is Incorrect
Document #: 159220

Read Mail Documents Change to Unread in Notes 4.5x and 4.6x Mail File
Document #: 153315

Read Mail Reverts to Unread When Running Notes Mail with Norton AntiVirus Version 6
Document #: 177600

Read Mail Is Reverting to Unread When Running Notes with McAfee Groupshield
Document #: 172652

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top