- Issue created by @donquixote
- 🇺🇸United States mfb San Francisco
I think the tldr is: These methods exist to either to provide improved logging or to work around bugs, cross-platform issues, unexpected weirdness, etc. in the php functions.
Many methods in FileSystemInterface do document why they exist / why to use them:
- "PHP's basename() does not properly support streams or filenames beginning with a non-US-ASCII character."
- "PHP's dirname() does not properly pass streams, so this function fills that gap. It is backwards compatible with normal paths and will use PHP's dirname() as a fallback."
- "When PHP's mkdir() creates a directory, the requested mode is affected by the process's umask. This function overrides the umask and sets the mode explicitly for all directory components created"
- "PHP's unlink() is broken on Windows, as it can fail to remove a file when it has a read-only flag set"
Admittedly, some of this is a little unclear, e.g. I think the dirname() documentation is supposed to say "parse streams", or rather "parse stream URIs", as dirname() is basically a string-parsing function; e.g. dirname('public://') === '.' whereas Drupal::service('file_system')->dirname('public://') === 'public://'
- 🇩🇪Germany donquixote
Thanks a lot!
So, it seems we are mostly trying to fix niche problems of specific functions, instead of trying to have a "swappable filesystem implementation".
Which also means that there are scenarios where the native functions are good enough.I might look into this more and propose improvements to the documentation.