c5fa470 made the extension check discard directories, but
only in the new code that currently only is used on Windows.
Let's add an equivalent check in the old code so that the
behavior is consistent across platforms.
This seems like an oversight in the old code, because
what's the point of loading user files if the titles
in them are going to be ignored for nearly all games?
This commit fixes the issue by making the first LoadMap
variant not overwrite entries and making the constructor
do everything in the opposite order. An alternative solution
would be to make the second LoadMap variant overwrite entries.
This makes it possible to catch errors earlier so that file systems
simply fail to load instead of behaving oddly. It also makes it possible
to check for errors that weren't checkable before, like the end of a
directory being after the end of the parent directory.
Instead of expecting callers to know how the size of directory file infos
relates to which files are in which directories, filesystems now offer a
GetRoot() method, and file infos offer a way to get their children. As
a bonus, m_FileInfoVector no longer has to be created and kept around
in RAM. Only the file info objects that actually are used are created.
Not initializing until the filesystem is used is good when
a filesystem is constructed and then never used, but nobody does that.
This simplifies the code a little and lets all methods be const.
Instead of using lots of small scattered reads to read the FST,
only one big read is used, which is more efficient.
This also means that the FST only allocates memory once and stores all
strings close to each other - good for the CPU cache. The file info
objects use pointers to this FST memory of containing data themselves.
Keeping around the big m_FileInfoVector containing objects with only
pointers is a bit unnecessary, but that will be fixed soon.
Instead of calling GetPathFromFSTOffset for every file info, FindFileInfo
now only looks at names in directories that are included in the path.
For the common case of searching for "opening.bnr", this means that
only root-level files and directories have to be searched through.
Some callers already have the file info, making the relatively slow
FindFileInfo calls unnecessary. Callers that didn't have the file info
will now need to call FindFileInfo on their own.
Some callers (i.e. ISOProperties) don't want the full path, so giving them
it is unnecessary. Those that do want it can use GetPathFromFSTOffset.
Not storing full paths everywhere also saves a small bit of RAM and is
necessary for a later commit. The code isn't especially pretty right now
(callers need to use FST offsets...) but it'll become better later.
GC/Wii filesystem internals shouldn't be exposed to other classes.
This change isn't especially useful by itself, but it opens up the
way for some neat stuff in the following commits.
You may want to read the PR #2047 comments before reading this.
Dolphin attempts to support an unencrypted type of Wii discs
that apparently is identified by a 4-byte integer at 0x60
being non-zero. I don't know what discs (if any) would be
using that format, so I haven't been able to test Dolphin's
support for it, but it has probably been broken for a while.
The old implementation is very short but also strange.
In CreateVolumeFromFilename, we read a 4-byte integer from
0x60, and if it's non-zero, we create a CVolumeGC object
instead of a CVolumeWiiCrypted object. This might seem like
it makes no sense, but it presumably worked in the past
because IsVolumeWiiDisc used to check the volume type by
reading the magic word for Wii straight from the disc,
meaning that CVolumeGC objects representing unencrypted Wii
discs would be treated as Wii discs by pretty much all of
Dolphin's code except for the volume implementation code.
(It wasn't possible to simply use CVolumeWiiCrypted, because
that class only handled encrypted discs, like the name says.)
However, that stopped working as intended because of ace0607.
And furthermore, bb93336 made it even more broken by making
parts of Dolphin expect that data read from Wii discs needed
to be decrypted (rather than the volume implementation
implicitly deciding whether to decrypt when Read was called).
Disclaimer: Like I said before, I haven't been able to test
any of this because I don't have any discs that use this
unencrypted Wii disc format, so this is all theoretical.
Later, PR #2047 tried to remove Dolphin's support for
the unencrypted Wii disc format because seemingly no
discs used it, but the PR got closed without being merged.
At the end of that PR, I said that I would make a new PR
with a better implementation for the format after PR #2353
was merged. Now that PR #2353 is merged (two years later...)
and PR #5521 is merged, the new implementation was easy to
make, and here it is!
Untested.
Normal users don't care about it. In fact, people care so
little about it that the Wii implementation of it was broken
starting from when it was implemented (eb65601) to 7 years
later (e0a47c1), apparently without anyone reporting it.
This gets rid of some assumptions that non-DiscIO code was making about
volume types. It's better to encapsulate as many of the volume type
differences as possible in DiscIO.
Made possible by PR #2353.
This file is pretty small now that it doesn't handle Wii
partitions anymore, so let's move its contents to Volume.cpp.
This is also more consistent with how blob creation works.
This happened to work without any problems because the only way for a
file system to be invalid was to not have the right GC/Wii magic word
in the unencrypted area, and a volume could not be created without
having the right GC/Wii magic word there. Now that file systems read
the magic word from a partition instead, a fix is needed.
I replaced m_OffsetShift with m_Wii in bb93336 to support
the decrypt parameter for read functions. Doing that is no
longer necessary, so m_offset_shift is now used like before.
By removing mutable state in VolumeWiiCrypted, this change makes
partition-related code simpler. It also gets rid of other ugly things,
like ISOProperties's "over 9000" loop that creates a list of
partitions by trying possible combinations, and DiscScrubber's
volume swapping that recreates the entire volume when it needs to
change partition.
VolumeDirectory doesn't support necessities like TMDs,
so thanks to 5.0-2172 (18968ab), EmulatedBS2_Wii crashes
when the inserted disc is a VolumeDirectory.
This commit fixes that.
This commit makes our DOL booting code very similar to our
ELF booting code. One exception is that the DOL booting
code still always calls SetupBAT. (Note that EmulatedBS2_GC
calls SetupBAT even if no disc is inserted.) I'm not sure
if there's a point to the difference, but I thought I'd
better avoid changing it so that I don't break anything.
For thread safety reasons, the currently inserted volume must
only be accessed by the DVD thread (or by the CPU thread if it
calls DVDThread::WaitUntilIdle() first). After this commit,
only DVDThread.cpp can access the volume, which prevents code in
other files from accessing the volume in a non-threadsafe way.
It's better to just let the calling code provide a volume
object instead of needing one SetVolume for each way of
creating a volume. This simplifies InsertDiscCallback and
is needed for the following commits.
The MemoryWindow.cpp strings should be the same as the
MemoryCheckDlg.cpp strings so that translators don't
have to translate very similar strings twice.
Also adding i18n comments. These strings are *very* easy
to misinterpret in my opinion.
JosJuice