ENOENT reading image from content/images — storage adapter or missing file?

Error context

Ghost logs an ENOENT error when it tries to read an image from the content/images directory. The stack trace appears to come from the storage adapter layer (ghost-storage-adapter-base), which sits between Ghost core and either the local filesystem or an external service such as S3. The goal is to determine whether the failure means the file is genuinely absent, or whether the configured adapter cannot locate an existing file.

Constraints and uncertainty

The exact message seems to vary by Ghost version and by the storage.active setting in the config file, and a misconfigured adapter can reportedly produce the same ENOENT even when files exist on disk. Debug logging and reproducing the request against a known-missing URL should clarify where the trace originates, but that has not been confirmed yet.

Separately, since Ghost currently delegates image resizing and optimization to the user or external services, there is an open question about whether relying on the adapter layer for any future built-in image pipeline would change how these errors surface.

Questions

• How can an ENOENT from a missing file be reliably distinguished from one caused by a misconfigured storage adapter?
• Which configuration keys and version assumptions determine the exact error text Ghost emits here?
• Is there any documented plan for built-in image optimization that would affect this adapter behavior?