Browse a site's recycle bin
Restore, move to second stage, or purge
One site's recycle bin, either stage, with search, filter and sort that SharePoint's own page does not give you. Find what somebody deleted three weeks ago, restore it, push it down to the second stage, or clear it out.
What it does
- What is in the bin, who deleted it, when, and where it came from.
- Which stage each item is in, because the second stage is where the large old things usually are.
- How much storage the bin is holding, which still counts against your quota.
How it runs
- Sign in and choose a site. One site.
- Find what you want. Pick the first or second stage, then search, filter and sort. Select all is available.
- Choose an action. Restore, move to the second stage, or permanently delete.
- Confirm, then it runs. The confirmation states the count and the action.
How it works
Before it reads anything, the page asks SharePoint which bins this account can open, with one single-item read of each stage. It always tries the site collection's bin first and falls back to the site's own end-user bin (the one a site member sees in SharePoint) only when SharePoint refuses with an access denial; a throttled or busy answer is never taken as a refusal. The check is repeated on every load, so signing in as a different account changes what the page offers, and the header names the account the calls actually run as.
The stage you pick is then read in full, page by page, and every search, filter, sort and page change after that works on the loaded copy without going back to SharePoint. A site that cannot be opened is reported as an error, never as an empty bin. In the background the page reads the site's subsite tree so it can tell this site's deleted items from its subsites'. The only-this-site choice appears only when that whole tree was read, because a partly read tree could attribute a subsite's item to this site.
Every action writes each item to a log file on this computer before the request that acts on it is sent, then records the outcome, so a crash part way through still leaves a record of what was about to change. Restores run shallowest first, folders before files, so a folder is back before anything inside it. Before restoring, ShareMaster checks that the folder the item was deleted from still exists and refuses the item if it does not, because SharePoint would otherwise quietly rebuild the missing folder. A name clash at the original location is skipped or resolved by renaming, as the conflict setting says, and an item somebody else has already restored is reported as no longer in the bin rather than as a clash.
When the page is working through your browser session, items are sent in batches the way SharePoint's own recycle bin page sends them, and a batch that fails is retried one item at a time so the failure lands on the item that caused it; otherwise each item is its own request. Moving to the second stage always goes item by item: it needs site collection administrator, and if the account is not one, ShareMaster tries to grant it for the duration of the action and removes it again afterwards, including when you stop. A grant it could not remove is shown on the page. A failed item is listed with its reason and the run carries on. A lost sign-in stops the run, and the items already done stay in the report. Stopping takes effect between requests: a request already sent is waited for, so nothing is miscounted.
Empty bin counts what is in the stage, asks SharePoint to empty it, reads the bin again, and repeats until a re-read finds it empty, because one empty can leave items behind. If a pass removes nothing, it stops and reports how many items are still there, which usually means a hold, a retention policy or a lock is keeping them. Leaving subsites out empties this site's own bin; including them empties the site collection's bin. A second-stage empty only exists for the whole site collection, so with subsites left out it is refused rather than reinterpreted. Every run is added to the recovered file history with a downloadable report.
What you need
- Site collection administrator to see and act on the second stage. With less than that you get the first stage only, and the page says so.
What it will not do
- Permanent deletion here is the operation, so it really is permanent. This is one of only three places in ShareMaster that deletes rather than recycles, and it is the one where that is the entire point.
- Restoring an item needs its original location to still exist. Where it does not, the restore is refused with a reason rather than dropped somewhere unexpected.
- Items expire on Microsoft's schedule regardless. A bin you looked at last week may have emptied itself in part.