Remove files using report
Stage 2, from a report you marked up
The second half of removing duplicate files, and it works from a report you marked up, possibly weeks ago in another session. ShareMaster re-verifies every marked copy against the live library before touching it, so a file that has changed or moved since the report is left alone rather than deleted on stale information.
What it does
- Which marked copies still exist, unchanged, and are therefore safe to remove.
- Which have changed, moved or gone since the report, and were left alone.
- What actually happened, per file.
How it runs
- Sign in and load your report. A duplicate CSV or Excel report from any earlier session.
- Approve and confirm. Per row, then a confirmation; permanent deletion needs DELETE typed in.
- It re-verifies, then removes. Each marked copy is checked live against the library, by identity rather than by path, as the removal reaches it: a file renamed or moved since the report is not assumed to be the same file, and a last-copy guard refuses to remove the only remaining copy in a set, whatever the report says. Recycle bin by default. A write-ahead log records each removal before it happens. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
How it works
The marked-up workbook or CSV is read back, and only rows you marked for removal are candidates. Rows in the same duplicate set that you left unmarked are treated as the copies meant to stay. Every marked copy is then listed for approval, all ticked; a row you untick is never sent to SharePoint. Permanent deletion additionally needs the confirmation where you type DELETE.
When the run starts it reads the current state of every approved copy, and of every unmarked copy in the same sets, library by library. Files are matched by their item in the library and the identity and size recorded in the report, not by their path, so a different file now sitting at the same place is not taken for the one you marked.
Each duplicate set is then judged on its own, and the surviving copy is settled first. At least one unmarked copy in the set must still be there and unchanged. If none is, because every copy was marked or the one meant to stay has gone, changed or could not be read, nothing in that set is touched. Only then are the marked copies considered, and each one is left alone if it has gone, is checked out to someone, has a different size or identity from the report, or its state could not be read.
The copies that pass are removed set by set, grouped by library: moved to the site recycle bin by default, or deleted outright if you chose permanent. What is about to be removed is recorded on this computer before each removal and the outcome after it. A file that cannot be removed is recorded as failed with the reason and the run goes on to the next set. If you stop the run, sets not yet begun are recorded as not attempted, and nothing already removed is lost from the record.
The outcome workbook lists every copy you approved and what became of it, with the ones not removed first, and it goes into Report History whether or not you save it. The tool never removes an unmarked row, never removes a copy it could not confirm is unchanged, and never acts on files that are not in the report.
What you get
An Excel workbook, named like contoso-duplicate-removal-20260901-142207.xlsx, kept in Report History whether or not you save it. Everything NOT removed is listed first, because that is what you are checking.
Outcomes sheet
One row per marked copy, and what became of it.
| Column | Example |
|---|---|
| Outcome | Left alone |
| Set | 17 |
| Site URL | https://contoso.sharepoint.com/sites/projects |
| Library | Shared Documents |
| File | Clients/Northwind/Proposal v4.pdf |
| Size (bytes) | 3,118,442 |
| Detail | Changed since the report was generated |
Summary sheet
The report used, the counts, and the storage reclaimed.
What you need
- Write access to the libraries the report covers.
- A report generated by the Duplicate file report. Stage 1 and stage 2 are independent: you can start here.
What it will not do
- It only ever acts on rows you marked. An unmarked row is not a candidate.
- The last copy in a set is never removed, even if the report says to. That guard applies in both recycle and permanent mode.
- Permanent deletion exists because a recycled file still counts against quota until the bin is purged, so recycling frees nothing on the day. It is reachable only through the per-row approval and then a dialog you must type DELETE into. There is no unattended path to it.
- A checked-out file is refused rather than forced.