When a collection or index is dropped, WiredTiger commits the removal of the table's metadata entry and then removes the data file. WT does not guarantee the file removal completes. If it fails, or the process crashes after the metadata change is committed, the file stays on disk with no metadata entry referencing it.

mongod does not clean these files up. Startup reconciliation (reconcileCatalogAndIdents) only considers idents listed in WT metadata (WiredTigerKVEngine::getAllIdents()), so a file with no metadata entry is never seen. The file persists across restarts until someone removes it manually (wt drop or rm).

Why this is a problem: users expect dropped data to be gone. A leftover file can hold personal or sensitive data that the user believes was deleted, which is a data retention concern, and it uses disk space indefinitely.

Possible leftover files:

• <ident>.wt: WT removes the file in place (the deferred rename below wasn't used or failed), and that removal fails, or the process crashes after the metadata commit and before the file is renamed or removed.
• <ident>.wt.<btreeId>.wtdrop (or .wtdrop.<N>): WT renames the file at commit and removes it after releasing the drop's locks (__wt_drop_pending_apply). The pending removal is tracked only in memory, and a removal failure is only logged. If the removal fails or the process crashes before it runs, the renamed file stays.

A crash after the collection is removed from the MDB catalog but before the WT drop is already handled: the table is still in WT metadata, so reconciliation drops it on restart.

A jstest reproducing the .wt case is attached in a comment.