Why some email get a $NoPurge field?

Hi Folks!

I was surprised to see that some emails get a $Nopurge field with sometime a date of 12.07.1989, or some of them without a date (permanently protected from archiving), even on recent emails.

Does anyone know why?

ps: those emails have no Followup.

Thanks.

Subject: Why some email get a $NoPurge field?

Quick search - see below

http://www-10.lotus.com/ldd/nd6forum.nsf/869c7412fe5d56b7852569fa007826e3/dd57673b6130670985256f41003897b1?OpenDocument

Subject: RE: Why some email get a $NoPurge field?

Thanks but I already read this thread. I know the meaning of this field.

What I want to know when (and why) this field is applied to an email??

Subject: RE: Why some email get a $NoPurge field?

Documents are not removed from mail file after they are archived

Technote (FAQ)

Problem

You select some documents to be archived and then select Actions → Archive → Archive Selected Documents. You then receive a dialog box “Do you wish to archive the selected documents now?” to which you click Yes, and then check your archive file. The documents that you selected to archive have been copied to the archive, but they have not been removed (deleted) from his mail file. Why does this occur?

Solution

This issue can occur for two different reasons:

(1) Notes 5.0.13, 6.0.4, 6.5.1, and 6.5.2 clients accessing a mail file on a Notes Domino 5.x server:

A regression issue has been discovered in relation to a fix made in SPR# KHAN5QMMMC. Specifically, documents are not being removed as expected when you manually archive documents, using one of the Notes Client releases noted above and when the mail file is on a Domino 5.x server. This regression was reported to Quality Engineering via SPR #BTLW5XYBD9 and has been addressed in Domino 6.5.3.

link

http://www-01.ibm.com/support/docview.wss?rs=475&context=SSKTWP&context=SSKTMJ&context=SSRNU3&context=SSRNUY&q1=%24Nopurge&uid=swg21094741&loc=en_US&cs=utf-8&lang=en

Subject: Why some email get a $NoPurge field?

Replication issues :

$NoPurge field

Upon review of documents that are not purged, they may contain the $NoPurge field. The $NoPurge field may contain a NULL string ( “” ) or a string containing a date ( “01/01/2008” ). In the case where the string is populated, the document in question will be purged after the date contained in the field, whereas a NULL value in $NoPurge implies the document will never be purged. In general, a document that contains this field may be a calendaring and scheduling document or a document flagged for follow-up.

Replication Settings

When purging documents that meet the criteria specified in “Remove Documents not modified in the last xx days”, the Updall task does so without creating a deletion stub. As this setting is specific to a database on a particular client or server, neither the configuration of the setting nor deletions replicate to other replicas.

It is also possible for the purged documents to replicate back from other replicas that do not have a similarly defined purge interval. The “Only Replicate Incoming Documents Saved or Modified After: date” setting prevents the purged documents from reappearing through replication.

Calendar issues after Archive:

Problem

A user experiences problems after archiving Calendar entries for repeating meetings and other entries from his/her Domino mail file.

Solution

This problem could occur if the parent documents have been archived by the user via Actions > Archive > Archive Selected Documents. Thus, the documents archive immediately regardless of the $NoPurge field they contain. The $NoPurge field tracks “expired” entries.

Copying and pasting the parent documents back into the Calendar view will NOT preserve the necessary “links” between these recurring meetings. For repeating entries, the APPTUNID and UNID values MUST be the same among all children of a parent document.

Invitees may experience the problem described in the technote "No Options To Respond to a Rescheduled Meeting or Participant Status Incorrectly Shows “No Response” (#1102276).

The customer’s only choices when this issue occurs are to:

  • Restore from backup the user’s entire mail file at a point in time before the Parent document was deleted

  • Delete and re-create the repeat meeting.

  • Educate users that when deleting repeating meeting documents, they must make sure the last occurrence/date of the repeating series has passed.

Note: It is recommended that all users check their mail files to make sure the “Do not delete documents that have responses” checkbox is enabled; this will prevent problems with future archives.

To access this option, open the mail file and select Actions > Archive > Settings. When the Archive Settings dialog box appears, switch to the Advanced pane to access the setting.