How to Detect Folder Changes with Before-and-After Snapshots

A folder snapshot gives you a before-and-after view of a directory without continuously monitoring it. You record the state at one point in time, then compare that saved baseline with the folder later.

This is useful for software folders, configuration directories, project exports, game mods, deployment packages and any other place where you want to know what changed without relying on memory.

FolderWatch works locally on Windows and stores paths, sizes, modification times and SHA-256 hashes in a snapshot. It then compares a later scan against the saved baseline.

What a snapshot can tell you

A comparison can classify files as:

• added;
• removed;
• modified;
• unchanged;
• inaccessible.

The last category is important. If a file or directory cannot be read, a careful tool should not pretend that unknown content disappeared.

FolderWatch records read failures and skipped areas as diagnostics instead of converting uncertainty into false “Removed” results.

Choose the right baseline moment

A snapshot is only useful if you understand what it represents.

Good baseline moments include:

• immediately after installing or extracting software;
• before applying a mod or patch;
• before changing project configuration;
• before a deployment or migration;
• after confirming a folder is in a known-good state.

Avoid creating a baseline while files are actively being generated, copied or updated. The filesystem is not frozen during an ordinary scan, so a rapidly changing directory can produce a partial view of different moments.

If the folder is busy, stop the relevant application when practical and scan again.

Why hashes are useful

File size and modification time are helpful, but they do not always prove content equality. A SHA-256 hash is calculated from file bytes and gives a stronger way to detect a content change.

FolderWatch includes SHA-256 hashes in snapshots so a file can be recognized as changed even when superficial metadata is not enough.

A matching hash means the bytes hashed by the tool were the same. It does not prove that the file is safe or trustworthy. Hashing is an integrity comparison, not a malware scan.

Save the snapshot separately from the folder when appropriate

If you are watching a directory for changes, storing the baseline inside that same directory can be confusing because the snapshot file itself becomes part of the folder state unless excluded.

For important comparisons, save the snapshot in a separate location or use an exclusion rule for the snapshot/report files you generate.

Keep the baseline file if you want to reproduce or audit a later comparison.

Use include and exclude rules carefully

FolderWatch supports wildcard rules and presets. These can reduce noise from temporary files or focus the scan on a specific part of a project.

But exclusions change the scope of your evidence.

If you exclude *.tmp, for example, the comparison says nothing about changes to those files. If you exclude an entire cache folder, you cannot later interpret the report as a complete record of everything that changed beneath the root.

FolderWatch saves rules with the snapshot so later comparisons can reuse the baseline scope. That is safer than silently comparing two different sets of files.

When changing rules intentionally, document why.

Understand partial scans

A scan can be incomplete because of:

• permissions;
• files locked by another process;
• paths that become unavailable;
• files changing while they are being read;
• reparse points or links that are not followed;
• other filesystem errors.

An incomplete scan should not be treated as complete evidence.

FolderWatch retains successfully captured files and reports skipped or inaccessible entries. If the baseline itself was incomplete, the comparison avoids unsupported claims about files that could have existed in the unknown area.

Retry the scan when files are available if the missing area matters.

A practical before-and-after workflow

1. Choose a quiet moment for the baseline.
2. Decide whether any exclusions are necessary.
3. Scan the folder and review inaccessible/skipped counts.
4. Save the snapshot outside the monitored folder when practical.
5. Make the intended change: install, patch, edit, copy or update.
6. Compare the folder against the saved snapshot.
7. Filter the result by Added, Removed, Modified or Inaccessible.
8. Open suspicious files or inspect their paths before acting on them.
9. Export a CSV if you need to keep or share the result.
10. If the second scan is partial, resolve the read failures before drawing broad conclusions.

This workflow is especially useful when you need evidence, not automatic cleanup.

Example: checking what a software update changed

Create a snapshot of the application directory before the update. After the update finishes, run the comparison.

Added files may represent new components. Removed files may be obsolete components. Modified files may be updated binaries or configuration files.

But the folder comparison alone does not tell you whether each change was expected. Compare the result with release notes, package contents or vendor documentation when that matters.

Also remember that many applications store data outside their install folder, such as in AppData, ProgramData or the registry. A snapshot of one directory does not represent the whole machine.

Example: checking a project export

Suppose you periodically export a static website or generated build. A folder snapshot can help confirm whether the output changed between runs.

If you expect only one HTML file to change but dozens of assets are marked Modified, investigate the build process. It may be regenerating files nondeterministically or changing metadata/content you did not expect.

If the output contains timestamps inside generated files, those files can legitimately hash differently on every build even when the visible result is similar.

Do not use “Removed” as permission to delete anything

A folder comparison reports state differences. It is not a cleanup recommendation.

A file shown as Removed is already absent from the current scan relative to the baseline. A file shown as Added may be important new data. A Modified file may contain user work.

Use the report to investigate. Do not turn it into an automatic deletion list.

Reparse points and linked folders

Following directory links blindly can create loops, duplicate scans or cross into locations you did not intend to include. FolderWatch does not follow reparse points as ordinary directories.

If linked content matters, scan the target explicitly and document that it is a separate scope.

Export reports with context

CSV output is useful for tickets, audits or troubleshooting, but include enough context for another person to understand it:

• the root path;
• snapshot date;
• comparison date;
• rules or preset used;
• whether either scan was incomplete;
• what action occurred between scans.

A list of paths without that context can be misleading.

What snapshots cannot prove

A folder snapshot is not a filesystem-wide atomic transaction. It cannot guarantee that every file existed in exactly the same instant while the scan ran. It also does not monitor changes continuously between the two snapshots.

If a file was changed and then restored to identical bytes before the second scan, the final comparison may show no content difference. If you need a continuous audit trail, you need a different class of monitoring system.

For before-and-after troubleshooting, however, a snapshot is simple and powerful: define the scope, create a clean baseline, record read failures, compare later, and interpret uncertainty honestly.