Mention missing files in corruption troubleshooting docs (#103962) (#…

…103968)

These docs talk about files whose contents are unexpected, but we should
also mention that files which are completely missing are also going to
be due to infrastructural problems.

docs/reference/troubleshooting/corruption-issues.asciidoc

@@ -38,13 +38,20 @@ well-tested, so you can be very confident that a checksum mismatch really does
 indicate that the data read from disk is different from the data that {es}
 previously wrote.
 
+It is also possible that {es} reports a corruption if a file it needs is
+entirely missing, with an exception such as:
+
+- `java.io.FileNotFoundException`
+- `java.nio.file.NoSuchFileException`
+
 The files that make up a Lucene index are written in full before they are used.
 If a file is needed to recover an index after a restart then your storage
 system previously confirmed to {es} that this file was durably synced to disk.
 On Linux this means that the `fsync()` system call returned successfully. {es}
 sometimes reports that an index is corrupt because a file needed for recovery
-has been truncated or is missing its footer. This indicates that your storage
-system acknowledges durable writes incorrectly.
+is missing, or it exists but has been truncated or is missing its footer. This
+indicates that your storage system acknowledges durable writes incorrectly or
+that some external process has modified the data {es} previously wrote to disk.
 
 There are many possible explanations for {es} detecting corruption in your
 cluster. Databases like {es} generate a challenging I/O workload that may find