We only use this class in one in one single function since its introduction with 12aa1071cb in 2021. If we do need it elsewhere we can always bring it back.
The cpp-ipc dependency was included in #13870; it was overlooked that
`install()` commands in the library would lead to ancillary files being
installed along side Dolphin on Linux.
`EXCLUDE_FROM_ALL` is now set in the `add_subdirectory()` call to
prevent cpp-ipc from being part of the installation.
In particular, the following files should no longer be seen in the build
logs or in the final builds:
```
-- Installing: /app/include/libipc
-- Installing: /app/include/libipc/condition.h
-- Installing: /app/include/libipc/buffer.h
-- Installing: /app/include/libipc/export.h
-- Installing: /app/include/libipc/def.h
-- Installing: /app/include/libipc/rw_lock.h
-- Installing: /app/include/libipc/shm.h
-- Installing: /app/include/libipc/mutex.h
-- Installing: /app/include/libipc/pool_alloc.h
-- Installing: /app/include/libipc/ipc.h
-- Installing: /app/include/libipc/semaphore.h
-- Installing: /app/lib/libipc.a
-- Installing: /app/share/cpp-ipc/cpp-ipc-targets.cmake
-- Installing: /app/share/cpp-ipc/cpp-ipc-targets-release.cmake
-- Installing: /app/share/cpp-ipc/cpp-ipc-config.cmake
-- Installing: /app/share/cpp-ipc/cppIpcConfigVersion.cmake
```
In 405baed805, we made the assumption that whether OpenAndroidContent
is able to create a new file depends on the open mode, the document
provider, and the positions of the celestial bodies. However, I'm
fairly sure that it can't create files at all as currently implemented.
First, ContentResolver.openFileDescriptor is documented as throwing
FileNotFoundException if the file doesn't exist. Now, the SAF
documentation is notoriously unreliable on matters like these, and
document providers can do whatever they want anyway, so we can't
actually trust this to mean that FileNotFoundException will always
be thrown if the file doesn't exist. But second, the Dolphin function
ContentHandler.unmangle is also unable to handle files that don't
already exist (unless the passed-in URI isn't mangled to begin with,
but to the best of my knowledge, there's no way to get a non-mangled URI
for a file that doesn't exist (unless you make assumptions about how the
document provider's URI scheme works, which we don't do in Dolphin)).
Summed up, it looks a lot like OpenAndroidContent can't create files,
or at the very least can't do so reliably.
Therefore I'm making DirectIOFile throw an assertion and return false
in situations where it's being asked to create a file under SAF. For
reference, there's no code in Dolphin that actually tries to create a
file under SAF. In all instances where we use SAF to write to files, the
file is created by the system file picker before it returns the URI of
the file to us.
What does this change gain us? First, if someone in the future tries to
use DirectIOFile to create a file under SAF, they'll be immediately
informed that this isn't supported rather than discovering it doesn't
work and chalking it up to SAF being bad for unpredictable reasons.
Second, we get rid of a call to File::Exists, which is a notable
performance improvement for game list scanning due to SAF and Dolphin's
"unmangling" being bad for reasons that unfortunately are entirely
predictable to those of us who have stared into the SAF void.
I've tested that game list scanning and game conversion still works.
Simonx22
JosJuice
Jordan Woyak
JMC47
oltolm
iwubcode
cristian64
Naim2000
LillyJadeKatrin
