Let us know how we can do a better job for you.


Send feedback

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

Fixed/Added in RV 3.5.2

Logic Issue

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

1

FixDATs are missing MIA flags

Fixed/Added in RV 3.5.2

Minor Bug

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.

1

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

Fixed/Added in RV 3.5.2

Crash

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)

1

Crash occurs if a RV temp archive cannot be deleted

Fixed/Added in RV 3.5.2

File Access

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)

1

Elevated RAM usage after refreshing all DATs

Fixed/Added in RV 3.5.2

Enhancement

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

1

Show more
Powered by Convas