Catch up to the removal of OSSL_STORE_open_file()

Remove references to it in documentation.

Unfortunately, it is too late to renumber symbols in libcrypto.num
and avoid the NOEXIST entry there.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3860)

3 files changed, 8 insertions, 24 deletions

diff --git a/doc/man3/OSSL_STORE_INFO.pod b/doc/man3/OSSL_STORE_INFO.pod
index 1b0f23347a..9b9e93b609 100644
--- a/doc/man3/OSSL_STORE_INFO.pod
+++ b/doc/man3/OSSL_STORE_INFO.pod
@@ -117,10 +117,10 @@ used by the application to get the objects in that file.
 This can be applied to all schemes that can somehow support a listing
 of object URIs.
 
-For C<file:> URIs that are used without the explicit scheme, or paths
-given to L<OSSL_STORE_open_file(3)>, the returned name will be the path of
-each object, so if C</foo/bar> was given and that path has the file
-C<cookie.pem>, the name C</foo/bar/cookie.pem> will be returned.
+For C<file:> URIs that are used without the explicit scheme, the
+returned name will be the path of each object, so if C</foo/bar> was
+given and that path has the file C<cookie.pem>, the name
+C</foo/bar/cookie.pem> will be returned.
 
 At the discretion of the loader that was used to get these names, an
 extra description may be attached as well.
diff --git a/doc/man3/OSSL_STORE_open.pod b/doc/man3/OSSL_STORE_open.pod
index 1a2626c944..0bc6d5ccfd 100644
--- a/doc/man3/OSSL_STORE_open.pod
+++ b/doc/man3/OSSL_STORE_open.pod
@@ -99,26 +99,14 @@ OSSL_STORE_register_loader().
 
 =head1 NOTES
 
-When unsure whether a given string contains a simple file or directory
-reference, or if it's a full blown URI, the question is how to figure
-that out.
-One way is to try OSSL_STORE_open_file() and if that fails, try
-OSSL_STORE_open().
-The other way is the other way around.
-Either way you choose, there are corner cases,
-F<file:/foo/bar/cookie.txt> might very will be a simple file reference
-on a system that supports the notion of volumes.
-
-This manual won't tell you which way is better, that's up to each
-application developer to decide on their own.
-However, there are some tools that can be used together with
+A string without a scheme prefix (that is, a non-URI string) is
+implicitly interpreted as using the F<file:> scheme.
+
+There are some tools that can be used together with
 OSSL_STORE_open() to determine if any failure is caused by an unparsable
 URI, or if it's a different error (such as memory allocation
 failures); if the URI was parsable but the scheme unregistered, the
 top error will have the reason C<OSSL_STORE_R_UNREGISTERED_SCHEME>.
-If you decide to use OSSL_STORE_open() with OSSL_STORE_open_file() as a
-fallback, those reasons can be good tools to decide if the fallback
-should be taken or not.
 
 =head1 RETURN VALUES
 
diff --git a/doc/man7/ossl_store.pod b/doc/man7/ossl_store.pod
index 59cfc7cea7..cda5ce47d6 100644
--- a/doc/man7/ossl_store.pod
+++ b/doc/man7/ossl_store.pod
@@ -59,10 +59,6 @@ only).
 
 =head2 A generic call
 
- /*
-  * There is also a OSSL_STORE_open_file() that can be used for file paths
-  * that can't be represented as URIs, such as Windows backslashes
-  */
  OSSL_STORE_CTX *ctx = OSSL_STORE_open("file:/foo/bar/data.pem");
 
  /*