The context for this is that i was symlinking files from a mod
installation that were identical to the unmodded game, for space
considerations, because i remembered having success with that in the
past, before the project made the switch to ghc's filesystem library, it
seems. <sub>(I was also much more pressed for space back then, but well,
i thought writing a small program to check for matches and link them for
me would be a good, not-so-difficult exercise...)</sub>
However i quickly started getting weird errors that it couldn't find
GAME.CGO or KERNEL.CGO even when i hadn't touched them. Initially since
i found that it occurred only when symlinking any files that were
earlier alphabetically, i assumed it was some kind of index mismatch,
but it was actually caused by a bug in an older version of
filesystem.hpp causing the `directory_iterator` to read everything after
a symlink as also a symlink, making them fail to be read properly:
https://github.com/gulrak/filesystem/pull/162
Adding `f.is_symlink()` is not as much of a change to the loop's
condition from the previous behavior as it might first appear. It seems
that even without that condition the iterator *was* reading symlinks
before, just incorrectly (and before ghc::filesystem, they were being
read just fine, iirc). With the new version, though, symlinks do have to
be accounted for explicitly.
Given that the library's major and minor version are both the same, i
don't expect there should be any breaking changes to the API, and i
didn't find any when i was testing but there might need to be more
investigation into that before merging. Also, without the added check
for `f.exists()`, the behavior is exactly the same as if, for some
reason, a fakeiso file the game needs just doesn't exist in the first
place (which has no real reason to happen in a normal installation of
the game): there's a decent chance it will either crash at some point
later during runtime, or something will happen like a level failing to
load causing Jak to trip infinitely. I thought it might be helpful to
have it fail right away in the case that, say, someone moved their
vanilla installation and staled their symlinks, but i'll defer to
maintainers' judgement on that point.
There was a single static path buffer being shared between multiple file
i/o threads. So sometimes you would end up using the wrong path for the
file, and getting size/data for the wrong file.
I think the original reason to have this buffer was just me being lazy
when we changed how project paths works a long time ago. It was a bad
idea in the first place.
Avoids blocking other IOP threads on IO.
Idk if it'll really help anything, but at least theoretically it might
stop some pathologically slow IO case from blocking the VAG buffer
switching.
twi