| Previous | Next |
| ERROR_JOURNAL_NOT_ACTIVE | ERROR_JOURNAL_ENTRY_DELETED |
ERROR_POTENTIAL_FILE_FOUND
A candidate file was located, but Windows cannot confirm that it is the intended file.
ERROR_POTENTIAL_FILE_FOUND is Win32 error 1180 (0x49C). The result is deliberately weaker than success: a search or tracking operation produced a plausible file, yet the available identity evidence is insufficient to prove that it is the same object the caller requested.
Where the result is meaningful
The code belongs to the group of results used around file replacement, link tracking, object identifiers, and change-journal processing. It can appear when software tries to recover a moved target from stale metadata or when a tracking component has only a partial match. The exact API remains essential because 1180 does not define which attributes made the candidate “potential.”
Why accepting the path immediately is risky
- a different file may have reused the old name after the original was moved
- a restored volume can contain an earlier generation of the same directory tree
- file ID, volume identity, or object ID information may be unavailable
- timestamps and size can match by coincidence
- a link-repair database may point to a candidate discovered before a later rename
Opening the candidate is useful for validation, but mutating or deleting it before validation can damage an unrelated file.
Evidence to capture
- original path and the candidate path returned by the tracking operation
- volume GUID and filesystem type for both locations
- file ID, object ID, size, timestamps, and any application-level identifier
- the search method, scope, elapsed time, and number of candidates considered
- whether the original volume was offline, restored, cloned, or remounted
For sensitive content, record a cryptographic digest only when policy permits reading the candidate. Do not put document contents into diagnostic logs.
Safe application behavior
Treat 1180 as “needs confirmation,” not as an ordinary found result. An application can compare its own embedded document ID, database key, signature, or expected hash before updating the stored link. Interactive software may present the candidate to the user with enough context to make a choice. Unattended software should leave the old reference intact and report an unresolved association unless it has a deterministic validation rule.
Retry and recovery
A repeated search can help after the original volume comes online or after tracking metadata is refreshed. Repeating the same query against unchanged state will normally return the same uncertainty. If no authoritative identity can be obtained, fall back to a normal “missing target” workflow rather than silently promoting a guess.
Difference from related codes
ERROR_NOT_FOUND means no requested element was found. ERROR_NO_MATCH says candidates failed the matching criteria. Error 1180 is between those outcomes: there is a candidate, but the caller still lacks enough evidence to call it the correct file. ERROR_JOURNAL_ENTRY_DELETED instead reports that historical change data needed for tracking is no longer retained.
Example
A document manager follows a saved reference after a user reorganizes an archive. Windows locates a file with the expected name on the expected volume but cannot establish the original object identity. The manager compares its embedded document UUID and discovers a mismatch, so it keeps the reference unresolved instead of opening the wrong customer record.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: Distributed Link Tracking and Object Identifiers
- Microsoft: GetFileInformationByHandleEx function
Looking for a different code? Search another status or error code.