We heard at PDC that WSS v3 is going to include a trash bin/recycle bin OOTB.  However, we’re a good bit away from an RTM release and many want something now.  The problem with implementing your own recycle bin in the current versions of SharePoint revolves around the document library event sink and the async nature of the events.  You can trap and handle the Deleted event, but the problem is the event is fired async.  This means that by the time your code is run, the file is already deleted… thus you can’t do anything with it.  So some creative types have come up with what I’ve seen to be a limited few options.

Over the last few days there’s been a flurry of SharePoint Document Recycle Bin library activity that work with the existing WSS v2 & SPS 2003 versions with roughly 4 different options out there (one unsupported, which I’ll still mention with a big disclaimer):

• First we have the method of creating a mirrored library using event sinks as method described in this article from the February 2005 issue of MSDN Magazine.  I’m not much of a fan of this option as your storage option just doubled in size… not really viable for those in corporate environments or have to pay for their hosting (including those corporate groups who pay “funny money” to other groups within their company for storage space, like, for example a SAN).
• Another option is something Todd Bleeker w/ Mindsharp released this week: Mindsharp’s FREE Deleted Items Document Library Custom List Template.  What’s awesome about Todd’s solution is that it’s zero-touch server deployment… ok, and that it’s FREE!  I had the op to beta his Deleted Items Document Library a few times the last few months.  It’s a fantastic solution that meets many user’s requirements.  Because it’s all in an STP, there are a few things that it can’t account for, mainly WebDAV.  For example, if you delete a document from a mapped drive, or from the Windows Explorer, well it just can’t account for that.  I had the pleasure last week to see someone’s (Angus’) reaction to seeing it for the very first time as the three of us blew off the last session of the Publisher Summit.  This is probably the best, least impact, solution for organizations who need this capability, meeting 90% of the needs.  What I haven’t done is pick through Todd’s code… what a case study!
• Dustin Miller has (err… will have) something he’s talking about called PowerRecycle (only vaporware at this point by his own admission).  Hard to comment on it since it’s not out there, but one thing he’s said is that “in order to work, will be doing quite a bit of ‘unsupported’ things”
  
  For that reason, I don’t believe PowerRecycle will ever see the light of day within corporate installations of SharePoint [who are familiar with Fitz].  Many companies pay for support contracts, and if you’re doing something unsupported, Microsoft won’t… well… support it.  If you’ve spent time in the newsgroups, you’ll see people who’ve had irreversible issues because they’ve tinkered with the database.  I won’t ever recommend something that touches the SharePoint database… even adding a trigger or selecting a single record out of the database.  Why?  Because there are ~usually~ work arounds.  And if there aren’t, then… well… there aren’t and you can make a request for a change in the next version of the product (as v3 has).  In this case, there are work arounds (see Todd’s and Joel’s solutions). I’ll be interested to see how Dustin implements PowerRecycle, but it won’t make it past my dev box.
  
  In a recent post, Dustin says of his unsupported method: “That's just the only way to REALLY fix the problem of the lack of a recycle bin in WSS v2”.  I disagree… and you’ll see why, just keep reading…
• Joel Oleson’s Recycle Bin has a very different implementation.  What’s unique here is Joel has built a ISAPI filter that intercepts the delete requests before they even make it to the SharePoint ISAPI filters.  When it finds a delete command, it dumps the file to the file system, then it hands the request off to other ISAPI filters (such as SharePoint’s filter) for processing.  Poof, all deleted documents are archived!  But… they are all on the file system… you have to have access to the server (physical, mapped drive, FTP, whatever).  For a production system, that’s not very viable… so a sysadmin would need to restore them for you.  Also, you need some sort of a cleanup job… I can see a very active system filling up the filesystem rather quickly.  This provides me the perfect transition to the real subject of my post…

Of all the above options, IMHO Todd’s is the best option.  Todd’s nails about 90% of the situations out there with zero touch to the server… and it’s incredibly easy to deploy.  However there are only a few limitations (that I’m willing to live with):

• It only works for new libraries: have existing libraries?  You’ll have to convert them to this new library to give them recycle bin functionality.
• It doesn’t work with WebDAV: It’s all wrapped up in an STP… it can’t account for WebDAV.

Joel’s solution provides the preservation of all deleted file… all the files (including WebDAV).  It also works for all existing libraries and can be mass applied at the scope of a virtual server.  What’s missing from Joel’s implementation?  A UI where an end user can restore a document.  Right now, only those with access to the filesystem of the SharePoint WFE server can retrieve the document.  How many end users or first level help desk folk do you know that have access to a WFE box?  I sure as hell hope that number is infinitely close to zero!

What’s really needed out there?  I think something of a cross between Todd’s and Joel’s solution.  Todd perfected the UI for, adding in multiple document templates for a library.  Joel’s solution works for existing libraries.  What else?  Something that does the following:

• Allows end users to restore their own documents they’ve deleted
• Allows anyone who has access to the document library where a document was deleted to see all documents in the “trash” from that library & restore them
• Allow sysadmins to easily restore specific documents
• Set a retention schedule for purging deleted documents

Sounds good huh?  How would I do it?  Let’s say you take Joel’s solution that saves a file that’s to be deleted from a library and stick it on the filesystem somewhere.  Then, you create an event sink handler that catches the Deleted event from the document libraries, grabs all the necessary information, grabs the file from the file system that Joel’s ISAPI filter persisted, and store all that information into a SQL database (no, not a SharePoint database, a separate database).

Now, you could write a SQL job to run every X days/weeks/months that could automatically purge anything that was X days/weeks/months old (providing a retention schedule).  You could also write a web app (wrapped up with appropriate security) to allow sysadmins, help desk jockies, or end users to restore their documents.  Or, even better yet, take Todd’s idea and extend the document library list template to include this web interface right in it!  What’s left is to just write a separate batch file that purges any files left on the file system as they were (1) saved by the ISAPI filter but (2) not moved into the database by your event sink so that library must not be publishing events and therefore want it’s documents stuffed in a recycle bin upon deletion.

I admit, this is just an idea and exists in vaporland (along with many of my other pet project ideas).  Maybe someone else will take this idea and the fame that goes along with it.  Go for it… for now, Todd’s and Joel’s solutions meet my needs (until a paying customer thinks otherwise… in that case, use my contact form in the menu above!).  If you aren’t happy with any of these work arounds, just stick it out and wait for SharePoint v3.