MPF
MPF copied to clipboard
[Problem] The "Overwrite?" window incorrectly identifies a Redumper dump as an Aaru dump
Version
- [ ] Stable release (version here)
- [X] WIP release 2983266
Build
- [ ] .NET 6.0 running on (Operating System)
- [X] .NET 8.0 running on 10
Describe the issue When trying to create an image in a directory that contains a finished Redumper image, MPF misidentifies it as an Aaru image.
To Reproduce
- Create a dump with Redumper.
- Without changing the output directory, attempt to create another dump. In my case, I changed the tool to DIC first but I don't believe this is necessary.
- See error
Expected behavior I would expect MPF to identify the completed dump properly as a Redumper image.
Screenshots
As you're trying to dump with DIC, it tries to look for a complete DIC dump (i.e. at least a .img file and the logs zip). It doesn't find it, so it goes through these methods: https://github.com/SabreTools/MPF/blob/2983266e8aaf0252f87728f3ecf254180265f16e/MPF.Frontend/DumpEnvironment.cs#L151 Aaru is the first one attempted, which only looks for the logs zip, and matches immediately. I would suggest a simple solution would be to just change the order and look for DIC first, then Redumper, then Aaru.
I'd personally say a more identifying check would be good, possibly in addition to reordering. For example, DIC should still be the only one producing an IMG while Redumper is definitely the only one producing a scram/scrap file.
Does this still happen on latest? The entire system of identifying files has been overhauled since this was opened and the newest stable includes those changes.
Was it only recently that you started checking inside the log zip file? In which case it should be fixed/better.
I still think as a precaution the order of checking in this function should change: https://github.com/SabreTools/MPF/blob/83a189a5d399ae81a8accc77eed2419073e3911d/MPF.Frontend/DumpEnvironment.cs#L154
Currently: Aaru -> DIC -> redumper Better: Redumper -> DIC -> Aaru
Reason being that Aaru is the least commonly used and has fewer specific output files. Although with the newer changes, I guess false positives are almost surely not possible?
The check inside of zips was part of the output file handling overhaul, yes. That's why I just want to have someone check. Then the order of the programs being checked won't matter and alphabetical would be fine.