Category
Administration IBM/Lotus Domino Programming
Here's a quick overview on the weirdness of soft-deletes and the ($Trash) folder in Domino e-mail. Some, not all, but some of our e-mail accounts do not correctly flush out their soft-delete documents in the trash folder after the designated 48 hours. If you've exposed the design of a mail account, then you know that the trash folder has a special structure to it, which is used by the hard coded name of ($Trash).
We've been in the midst of a very complicated upgrade cycle that includes R5 clients. I was not present at the first stage of the upgrade process, and not every IBM Best Practice was followed. The consequence of some earlier decisions has produced ($Trash) folders which never empty.
We do have analysis tools that can tell us many things about our databases, but there is nothing in the Domino Object Model (DOM) which allows access to documents which have been marked as soft-delete. It's a feature. After all, if I soft-delete a document, it would be a problem for it to show up in a document collection containing current documents. Soft-deleted documents are not given any easy DOM. Go ahead and try to create a document collection of the ($Trash) folder--your count will always be zero.
But there are ways to gauge the size of the trash contents.
Method one: count everything else. If I look at the database properties, I can read the total count of all the documents. Everything. The ACL is a document, the design elements are documents, the mail rules and so on are all documents. Even the trash documents !
If I count the documents in the ($All) view of my mail file and subtract it from the total number of database documents, then I'll get a set which includes the trash documents. If the difference is, say, 50, then I know there isn't much in the trash. On the other hand, if the difference is 4,276, then I know there are a lot of documents that need to be cleaned out of the trash.
Here's a quick excerpt of my code that produces an estimated trash count:
Set allview = svrdb.GetView({($All)})
allviewcount = (allview.EntryCount)
alldbcount = (svrdb.AllDocuments.Count)
doc.trashcount = alldbcount - allviewcount
Method two: run a console statement and read the size of the ($Trash) view. A faster method is to let the server report on the database properties. Entering, "show database names.nsf" will return the number of documents (and their types), including deletion stubs (very useful information, but not needed for our analysis), and the sizes of the application's view.
If there are a lot of documents in ($Trash), then we can expect a corresponding increase in the size of the view. This is a harder value to interpret, but it's clear that 0 means empty and 45K suggests a lot of documents (as it turns out, over 2,700 documents).
Here's a snippet of my code for capturing the console statement:
consoleReturn = session.SendConsoleCommand( dbsrv, {sh database } & doc.filepath(0) )
doc.databaseinfo = Today() & Chr(10) & Chr(10) & consolereturn
I'm taking the string that is returned from the SendConsoleCommand and storing it in a document. On the form which displays the document, I use a computed text value that is formatted for Courier (so, the columns all line up, nice and neat). You'll see that I've added the function Today(), because I need to know the last time I took a snapshot of the database values.
When we find a mail account that isn't correctly processing soft-delete documents, we manually purge out the documents and then reset the expire date.
Here's a code sample for resetting the expire date:
If db.getoption(dbopt_softdelete) Then 'Needs to be set and reset
db.undeleteexpiretime=49
db.undeleteexpiretime=48
Else
Msgbox "Soft Delete Is Not Enabled"
End If
Now you can ($Trash) talk with the best of them.
Technorati Tags:
($Trash),
IBM/Lotus Domino