Empty directories and 0 byte files are deleted from locked branches and ToSorts

Any branch or ToSort can be locked in the tree and is signified as such with a lock icon. This implies that the directory will not be modified and no files will be deleted. However, even if a directory like a ToSort is locked, 0-byte files and empty directories will be deleted during a fix. This issue is problematic for some collectors who keep 0-byte files or directories in their archives that they want to keep. For example someone may create a 0-byte file placed in a directory that has a filename that indicates where they found the content. Also, many old PC games present in TDC and eXoDOS sets contain intentional empty directories. Steps to reproduce: Create a 0-byte file and place it in a non-Primary ToSort Create an empty directory and place it in your non-Primary ToSort Lock the ToSort directory in the tree Scan the ToSort so that the file and directory are logged in RV's cache Perform a fix while the ToSort is locked Notice that the 0-byte file and empty directory are deleted Expected behavior: 0-byte files and directories should not be deleted if the directory is locked as indicated in the tree

DatVault can throw invalid JSON error

Malformed JSON can cause DATVault to throw an error

Missing status for "In DAT merged, delete" in ROM details grid

RomVault displays a broken image in the ROM details grid when a deduped ROM needs to be deleted. Steps to reproduce: Scan an archive Load a DAT for that archive that has a matching file flagged with the "dedupe" status Find Fixes and notice the broken image in the ROM details grid Expected behavior: A descriptive icon should display in the ROM details grid instead of a broken image icon. (screenshot)

FixDATs are missing MIA flags

When a FixDAT is created, RomVault omits the mia=yes flags for MIA files. Steps to reproduce: Add a DAT to your DatRoot that contains MIA flags, for example No-Intro Sinclair ZX Spectrum Select the DAT in the tree Click "Generate Reports" to create a FixDAT and save the file somewhere Open the newly created FixDAT and notice that the MIA roms are missing the mia=yes attribute Expected behavior: These flags should be preserved in FixDATs.

CMP DATs are interpreted with incorrect character encoding

There is a discrepancy between how characters are interpreted in CMP formatted DATs vs XML formatted DATs. XML dats are interpreted correctly with UTF-8 characters while CMP dats are not. Steps to reproduce: Refer to screenshots for an example Expected behavior: All characters should be interpreted with UTF-8 encoding regardless of the original dat format (screenshot 1 | screenshot 2)

Crash occurs if a fix requires the 7z cache but no ToSort directory exists

If a 7z file needs to be torrentzipped using the 7z cache, but a ToSort directory does not exist, then RomVault will crash. Steps to reproduce: Start a clean instance of RomVault with no default directories Add a dat to your DATRoot Add a solid 7z archive that contains files needed by the DAT somewhere in your RomRoot in an incorrect directory Scan your ROMRoot so the 7z archive is hashed Check with explorer and ensure no ToSort folder exists, delete it if it does exist Fix ROMs Notice that RV crashes when attempting to decompress the 7z archive to the Primary ToSort Expected behavior: If the Primary ToSort directory does not exist, it should automatically be created at the time of the fix, AND If a cache ToSort is defined but does not exist, it should automatically be created at the time of the fix. (screenshot)

Crash occurs if a RV temp archive cannot be deleted

If a RV temp file is encountered during a scan, RV will try to delete it. A crash will occur if the temp archive is open by another process. Steps to reproduce: Perform a fix that will have RomVault create a large zip archive, for example a compressed DVD-sized ISO While RomVault is compressing the archive, force the application to close using the task manager Open the temporary archive in another application so that the file is locked Test that the file is properly locked by trying to delete the temp archive with explorer After you confirm the file is locked, start RomVault back up Scan the directory where the temp archive resides When the scan reaches the archive, RV will attempt to delete the temp file and crash Expected behavior: RomVault should present the user with a halting error notifying that the temporary file could not be deleted, OR RomVault should flag the file as locked and proceed with the rest of the scan. (screenshot)

Crash occurs when generating Fix DATs for directories using Single Archive

If you generate fixDats on directories that are using the Single Archive setting with “Add SubDirs if multiple roms” with File as the archive type then RomVault will crash with an error. The text reports will not cause a crash, but the reports will not include any information from the directories using Single Archive. This may also occur under other directory setting scenarios but this is unconfirmed. Steps to reproduce: Put the Redump PlayStation 3 DAT in your DATRoot Change the directory settings to: Archive Type = File + Override DAT, Single Archive = Add SubDirs if multiple roms (see screenshot 1 below) Apply the directory settings so the DAT is reprocessed Generate a fixDAT for the PS3 directory from the tree Notice a crash will occur Expected behavior: FixDATs should be generated properly using the original DAT settings (not the effective settings due to directory rules) (Screenshot 1, 2)

Cache can become unstable and trigger errors on every change

In certain scenarios the cache can become unstable and trigger errors. These errors occur during startup when the problematic area is read and during interactions with the tree. This error renders RomVault effectively unusable. (screenshot)

Corrupt CHDs lose their corrupt status

If a CHD is scanned and flagged as corrupt then rescanned or the DAT is updated, then the corrupt status is removed.

Some edge case statuses are missing images

The following ROM statuses are missing images: R_InDatMerged_Corrupt R_InDatMerged_MoveToCorrupt R_InDatMerged_UnScanned R_InDatMIA_Corrupt R_InDatMIA_MoveToCorrupt R_InDatMIA_CorruptCanBeFixed R_InDatMIA_UnScanned

DATs with single archive directory settings are reprocessed on every DAT update

DATs that have single archive settings set to true are reprocessed on every regular DAT update even if the DAT did not change. Steps to reproduce: Place a DAT in a folder in your DATRoot Change the directory settings to use Single Archive Apply settings Click the Update DATs button and notice the DAT is processed again. This occurs every time you choose to Update DATs Expected behavior: Update DATs should only process DATs if there has been a change (add/update/delete)

Registration window uses default icon in task bar

The registration window does not have a custom icon defined, so it uses the default form icon when viewing in the task bar Steps to reproduce: Select Registration from the Settings menu Hover over the RV taskbar icon Notice the registration window uses the default windows forms icon Expected behavior: The RV icon should be used (screenshot)

Elevated RAM usage after refreshing all DATs

RomVault appears to consume a significant amount of RAM while doing a full dat refresh. When the process is complete, RAM does not return to normal usage levels. Steps to reproduce: Start with opening a large RV instance so the issue is more pronounced Take note of your RAM usage before doing anything else Refresh all DATs Notice while dats are refreshing RAM usage is elevated Notice when the process completes RAM usage remains high Expected behavior: RAM should be freed up after the Refresh All DATs process completes and return to a normal level

Files can be stuck in a "cyan" state until rescan

Its possible for an uncompressed file to be stuck in a cyan state if you start scanning and the file becomes unavailable before hashing can complete. This results in a situation where "Find Fixes" will not be sufficient to perform a fix. Steps to reproduce: Setup your RomRoot to target a mapped network drive Place a large uncompressed file somewhere in your RomRoot, approximately 2gb or larger to ensure you have enough time for the next steps Scan the RomRoot While the file is scanning, quickly disconnect the network drive Notice the file appears in the RomVault UI but it only has a size and no hashes Reconnect the network drive Attempt to fix as normal by doing "find fixes" then "fix roms" Notice the fix will not work Expected behavior: The error message should prompt the user to rescan since a file with no hashes at all is not a supported scenario. (screenshot)

Crash occurs when moving a file open by another process

If a file is open by another process and RV tries to move the file as part of a fix, RV will crash. Steps to reproduce: Place a file which is needed by a DAT in your ToSort Configure the directory rule for the DAT to "Files" archive type with "Override DAT" option selected Scan the ToSort Open the file in your ToSort in another application so that is locked Confirm the file is locked by trying to delete it with explorer After confirming the file is locked, have RV perform a fix which should attempt to move the file Notice RV will crash when it attempts to move the locked file Expected behavior: RomVault should present the user with a halting error and update the cache, OR RomVault should flag the file as locked and continue with the remainder of the fix operation (screenshot)

Readable corrupt zips that require fixes cause repeated errors

If a zip file is corrupt but readable, and the archive needs fixing (E.g. deletions of matched files), then RomVault will throw an error while fixing. This error will occur during every fix run as RomVault will keep attempting to fix the corrupt archive. Steps to reproduce: Place a corrupt archive in your ToSort that is readable where some files can be extracted but others cannot Place a DAT in your DATRoot that should match some of the files in the corrupt archive Update DATs Scan the corrupt archive Find fixes and fix ROMs An error will occur when RomVault tries to delete files from the archive Attempt to fix again, and notice the same error will occur Expected behavior: Suggestion: RomVault should not attempt to delete any files from corrupt archives since there are likely issues that would prevent recompressing the archive Contact johnsanc for example archive. (screenshot)

DatVault can load with no Groups displayed, refresh causes crash

Sometimes DatVault loads with no Groups Filter in the left rail. This seems to occur most frequently when DatVault loads with an empty DatRoot folder. Steps to reproduce: Create a new empty test instance of RomVault Load DatVault Close DatVault Reload DatVault using the right click shortcut (for some reason this method of opening seems to reproduce the issue more frequently than the top menu) Keep trying step 4 until the missing Groups Filter issue is reproduced Once the Groups Filter is missing, press refresh button Notice RomVault crashes after pressing the refresh button Expected behavior: The Groups Filter should always consistently display, and pressing the refresh button should not cause a crash (Screenshots: 1, 2)

Missing ROMs from "Single Archives" are included as orphaned ROMs in the wrong FixDAT

If a directory with Single Archive = No Subdirs has missing ROMs, then these ROMs are included in the fixdat from the previous collection. This results in a fixdat with content that does not belong which also cannot be parsed properly without potentially thousands of "Trying to add a ZipFile to a Dir" errors since the roms are orphaned in the fixdat. Steps to reproduce: Start with a fresh RV instance Place two DATs into your DATRoot in the same folder (Example: Redump Acorn Archimedes and Nintendo Gamecube) Configure the lowest DAT in the tree with Single Archive = No Subdirs with Archive Type = File with Override DAT set to true (Nintendo Gamecube) Generate fixDATs for all directories Notice only one fixDAT is created, and that this fixDAT contains content from both source DATs and files from the Gamecube DAT are orphaned without a set Expected behavior: RomVault should generate the fixDATs correctly with the appropriate content for each and no ROMs should be orphaned without a set. (Screenshot: 1, 2, 3, 4)

The "In DAT merged, move to ToSort" scenario displays a broken image in ROM details grid

RomVault is missing a fix status for "In DAT merged, move to ToSort". When this scenario occurs it appears as a broken image in the ROM details grid Steps to reproduce: Add a DatVault dedupe DAT to your DATRoot Place one of the deduped ROMs in the appropriate RomRoot directory for the DAT Scan the directory Notice the ROM will appear as a light cyan color indicating it is unneeded Select the directory and find fixes Notice the ROM details grid displays a broken image for the ROM should be moved to ToSort Expected behavior: The ROM details grid should display an icon indicating that the merged / deduped ROM will be moved to ToSort (screenshot)

Crash occurs if a RV temp archive is open by another process during a rename

RomVault creates temporary files when compressing an archive during a fix. If this temporary file is open by another application at the time RomVault tries to rename it to its final archive name, a crash will occur. Steps to reproduce: Perform a fix that requires compressing a large file so that you have time to open the file while RV is processing Open the temporary archive in another application when its nearing the full archive size, such as Sublime Text Notice when RomVault attempts to rename the archive a crash occurs Expected behavior: RomVault should display a halting error and update the cache, OR RomVault should abandon the temp archive and continue with the rest of the fixes (screenshot)

Crash occurs during Full DAT creation if DAT has missing rom names

RomVault will crash when trying to make a Full DAT if a component DAT has a rom that is missing a filename. Steps to reproduce: Load a DAT that has a missing rom name Create a Full DAT from the tree that include the DAT with the missing rom name Notice RV will crash with an error Expected behavior: An error should display to the user notifying that the DAT could not be created due to missing required information, OR RomVault should create the dat as is even if the information is invalid (after all, RomVault was able to load the DAT initially...) (screenshot 1, 2)

Crash can occur during a cache backup if not enough space

A crash occurs if the drive where the cache is stored runs out of space, for example during a mid-scan/fix cache backup. Steps to reproduce: Setup a large RomVault instance in a location that has limited space, less than 2x the size of the cache file Change the cache backup timer to 5 minutes Start a scan that is long enough to trigger the cache backup When the backup occurs, RV will crash with a "There is not enough space on the disk" error. Expected behavior: RomVault should halt and prompt the user to free up space to save the cache. The user should be able to free up space then acknowledge the error to retry saving the cache. (screenshot)

ZipMove is sometimes not used if the archive to be moved contains a 0 byte file

This occurs if the zip to be moved resides in a path that comes before the destination directory alphabetically. (E.g. DirA → DirB: ZipMove not used. DirB → DirA: ZipMove is used.) (screenshot)

Fixes from 7z archives to Uncompressed sets do not use the 7z cache