Confusing and unhelpful error message for file path issues

I came across this issue while doing the Bug-smash triage.

I am able to reproduce the issue with the steps mentioned in the issue 🐛 Directory "private:" is created if file_private_path is not set Active

I disabled "file_private_path" settings.
Installed one test module which had field config with private file upload.
Create new content using devel generate

It shows following warnings

drush devel-generate:content 2 --bundles=article
 [warning] is_dir(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? FileSystem.php:515
 [warning] is_writable(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? FileSystem.php:534

In FileRepository.php line 96:

I believe this issue should be closed so we can dedicate effort in the single issue.

You misunderstand what this is about. The "private" scheme is not part of configuring PHP, it is part of configuring Drupal. The language of the warning(s) is incorrect and misleading.

Ahh, I got your point.
Thanks a lot for correcting me.

I was in impression about the related issue mentioned in the ticket.

Anyway, I can take a look at the message tweak.
I believe this should be easier to fix.

Hi @brad.bulger
I did debug about the error.

It seems the error is coming from the php side.
I did run the following code in the php runtime online at https://3v4l.org/

<?php
print is_dir("public://abc/def.txt");

It gave me the following error
Warning: is_dir(): Unable to find the wrapper "public" - did you forget to enable it when you configured PHP?
So I believe we don't have any control over the message since it is coming from php.

Now regarding conveying to users about the issue:
We are already returning FALSE from here https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

Which in turn throws the InvalidStreamWrapper exception.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/file/...
It is also visible in the command run message.

So to change the error, we'd have to suppress the PHP error and detect the failure and then issue our own message. Yes, that seems like it would be troublesome. Detecting the undefined scheme ourselves at some point might be the better approach, considering how many different situations it comes up in.

Thanks for looking into it.