How Can a Cleanup Script Safely Verify Files Before Deleting Them?

0
5
Asked By MellowCedar47 On

A cleanup directory may contain files created by people or by other jobs, so checking only the path and file age is not sufficient. I'm considering writing an ownership manifest when each artifact is created. It would record a run ID, normalized path, size, and hash, and the cleanup script would require those values to match before deleting anything.

The script would support PowerShell's normal confirmation flow with SupportsShouldProcess and ConfirmImpact set to High, allowing candidates to be reviewed with -WhatIf before removal. I'm also considering rejecting paths outside the resolved root, refusing reparse points, failing closed when the manifest is incomplete, logging file identity during validation and deletion, and separating discovery from the actual removal step.

What other safeguards should be included? In particular, how can the time-of-check/time-of-use gap be reduced if another process could replace or modify a file between validation and deletion?

3 Answers

Answered By QuietHarbor8 On

The safest design is usually to avoid sharing a directory and filename between producers and cleanup jobs. Give each artifact a unique name, such as one containing a GUID or ULID, and keep temporary output in a dedicated directory. Then ownership is established by the creation workflow rather than inferred later from metadata.

For the race itself, atomically rename or move a file into a quarantine area before inspecting or deleting it. Alternatively, open it with exclusive access so another process cannot replace or modify it while you work. A manifest, path check, hash, and age check can still be useful as defense in depth, but they cannot make separate validation and deletion operations completely atomic.

BrightMap22 -

An exclusive handle is a good option when the producer has finished writing. If the file cannot be opened with the required sharing restrictions, the cleanup job should skip it and try again later.

Answered By SilverOtter31 On

A hash proves that the contents matched when you read them; it does not reserve the path for you. Another process can replace the file after the hash calculation, so there is no perfect solution using ordinary path-based checks alone. If the threat matters, coordinate with the producers, use a lock or exclusive file handle, or atomically move the item to a private quarantine directory before deleting it.

Also define ownership operationally. If several scripts can create or modify the same files, they should share a protocol for naming, locking, completion markers, and cleanup responsibility. Otherwise every additional validation rule just creates more edge cases without fixing the underlying coordination problem.

Answered By NorthwindLime5 On

Constrain the whole operation to a resolved, canonical root and compare canonical paths rather than string prefixes. Reject paths that escape the root, refuse unexpected reparse points or links, and treat missing or malformed manifest records as a reason to skip the item rather than delete it. A unique artifact identifier in the filename or manifest is often more reliable than trying to prove ownership from timestamps alone.

Discovery and deletion should be separate phases: produce a reviewable candidate list, record the identity and validation results, then revalidate immediately before removal. Use -WhatIf and SupportsShouldProcess for the final action, and log skips, failures, and successful deletions.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.