This is not required due to `createFileInfos` always being run before we
get to this point (I believe this was added after the initial code to
check existence was added).
This flow is covered in
`BeatmapImportTests.TestImportThenReimportAfterMissingFiles`, which
still passes with the change.
While this check isn't doing any harm, as I'm going through the flow for
import-skipping, less checks are appreciated.
One of my pending work items for post-realm merge.
The lowest-level import task is no longer asynchronous, as we don't want
it to span multiple threads to allow easier interaction with realm.
Removing the `Task` spec simplifies a heap of usages.
Individual usages should decide whether they want to run the import
asynchronously, by either using an alternative override or spooling up a
thread themselves.
This is one step closer to sanity in terms of physical files. As per the
comment I have left in place, we really should be checking file sizes or
hashes, but to keep things simple and fast I've opted to just cover the
"missing file" scenario for now.
Ran into this when testing against a foreign `client.realm` by:
- Noticing a beatmap doesn't load
- Deleting said beatmap
- Downloading via beatmap overlay
- Beatmap is restored but still doesn't work
Note that I've kept the logic where this will undelete an existing
import rather than create one from fresh, as I think that is beneficial
to the user (ie. it will still keep any linked scores on restore).
I've updated all cases where we should have been using
`GetDisplayString()` anyway, but left the `ToString()` implementations
in place for safety. They should probably be removed in the future.
This only occurs on upcoming changes I have (occurred when switching
existing skin import tests across to realm). Unsure why it was set to
`true`, seems like a weird oversight.
