| Previous | Next |
| ERROR_IEPORT_FULL | ERROR_REMOTE_STORAGE_NOT_ACTIVE |
ERROR_FILE_OFFLINE
This file is currently not available for use on this computer.
ERROR_FILE_OFFLINE is Win32 error 4350 (0x10FE) and belongs to offline or tiered file recall. The system description identifies the immediate condition but does not identify the caller, object, policy, device, service instance, or transition that produced it.
Interpret this result at the API boundary that returned it. Capture it before logging, cleanup, or another Windows call can replace the thread-local last-error value. Compare the recorded inputs with the documented precondition for offline or tiered file recall rather than starting with a broad system repair.
Where the result appears
- This result can surface during opening a file marked offline by hierarchical storage.
- This result can surface during cloud or remote-tier placeholder recall.
- It can surface during backup software enumerating files whose data is not local.
- It can surface during an application requesting content while the recall provider is unavailable.
Likely causes
- the file data resides on remote or removable storage and has not been recalled.
- the tiering provider cannot currently retrieve the content.
- policy permits metadata access but not immediate data hydration.
- the caller disabled recall or used an API mode that avoids bringing data online.
Diagnostic sequence
Diagnosis of it starts with the exact request type: read, write, create, transition, validation, cancellation, or administrative action. Identify the object generation and subsystem owner, then decide whether the failure happened before side effects, during a partial transition, or after completion. This ordering matters in offline or tiered file recall because a blind retry can hide stale state or repeat a non-idempotent change.
- record path, file ID, attributes, reparse tag, and provider.
- record whether metadata access succeeds while data access fails.
- record recall or hydration events and network state.
- record provider service health and user authentication.
- record requested access mode and timeout.
Correlate it with the owning component’s operational log, the Windows System log, and any subsystem trace. Telemetry for it should preserve native identifiers such as a path or file ID, handle generation, node or peer identity, policy ID, object version, offset and length, or transaction token. Retain decimal 4350, hexadecimal 0x10FE, and the producing API even when a localized message is also shown.
State boundary to prove
The decisive boundary for it is whether the file data resides on remote or removable storage and has not been recalled. Prove or disprove that proposition using path, file ID, attributes, reparse tag, and provider together with whether metadata access succeeds while data access fails. When observations for it disagree, preserve both and inspect the transition between them instead of choosing the more convenient value.
A focused validation for it should recreate the relevant part of this situation: an archive stub is visible in Explorer but its tape or cloud tier is unavailable. Logging the offline attribute directs support to recall infrastructure rather than path permissions. The negative case should keep the responsible condition unchanged and confirm error 4350; the recovery case should change only that condition and verify a successful result without an unrecorded side effect.
Handling, retry, and recovery
Initiate recall through the owning storage provider, wait for the file to become online, and retry with bounded timeouts. Applications should expose recall progress instead of interpreting the file as deleted.
Retry it only after evidence shows a change in offline or tiered file recall. Initialization, asynchronous completion, recall, or service readiness can justify bounded backoff; malformed metadata, invalid identifiers, policy rejection, unsupported versions, and integrity failures require correction. Before repeating a write or configuration operation after it, query completion state explicitly.
What to log for support and telemetry
- log decimal 4350, hexadecimal
0x10FE, and the producing API. - log the target object and observed offline or tiered file recall state.
- log caller identity, process and thread IDs, machine or node identity, and UTC time.
- log attempt number, elapsed time, previous result, and any partial side effect.
- retain the first lower-level or component-specific error before Win32 translation.
Difference from nearby codes
It means the namespace entry exists; ERROR_FILE_NOT_FOUND means the path itself was not found.
Practical example
An archive stub is visible in Explorer but its tape or cloud tier is unavailable.
Developer and administrator guidance
Code that handles it should keep its Win32 domain visible across exceptions, RPC responses, and JSON or REST wrappers. Administrators should verify the subsystem evidence before changing policy, deleting state, forcing failover, or replacing storage. Recovery is demonstrated only when a test observes 4350, changes the responsible condition, and confirms that the same operation succeeds without hidden data loss.
References
- Microsoft: System Error Codes (4000–5999) — reference for error 4350.
- Microsoft: Offline Files — reference for error 4350.
- Microsoft: File attributes — reference for error 4350.
Looking for a different code? Search another status or error code.