ErrorTimeStamp can occur when file has not changed

Cannot Reproduce

File Access

Under certain scenarios, RomVault can trigger an error during scanning which shows "ErrorTimeStamp". Its my understanding that RV checks the timestamps of all files in a directory to determine which files have changed and need to be hashed in that directory. It appears that sometimes a file's actual modified time as shown by viewing the properties of the file can differ from the time shown in the Windows Explorer directory view. I believe this discrepancy is causing the ErrorTimeStamp error to occur consistently even if the file has not changed. Cannot reproduce consistently, but here is what I observed: Downloaded a file with JD2, which failed and was left in a "invalid download" state and was named with a ".zip.part" extension Scanned the file and error occurred Confirmed that the modified timestamp of the file matched exactly what was logged in the cache using the fileDateTime.exe debugging application Noticed that the modified time in the windows directory view differed from the file properties Tried to rename the file to confirm it was not locked Noticed that upon renaming the file, the directory view timestamp for that file was updated to the proper time Renamed file back to the original name Rescanned, and this time the file was properly hashed without error Expected behavior: If they are not already, ideally timestamps should be taken from the same source for all RV actions. ErrorTimeStamp should not occur if the file did not change. (screenshot)

1

DAT merge conflict with first DAT in directory

Reproducible

Logic Issue

In all versions of RomVault past 3.5.2 a DAT merge conflict can occur when updating DATs. When this occurs the conflict is always between the first DAT in a directory and another unrelated DAT in the same directory when you use auto-created DAT directories. Because this issue cannot be consistently reproduced, we suspect that its due to a race condition when processing DATs.

1

The "Only Keep Complete Sets" setting can leave empty directories

WIP Testing

Fixing

The "Only Keep Complete Sets" setting can leave empty directories if files need to be deleted or moved to ToSort. Steps to reproduce: Add a Redump DAT that contains bin and cue files Configure the directory to only keep complete sets and store the sets uncompressed (File) Add a complete set for the DAT and scan so that the set only contains green "have" status Do find/fix if needed to ensure the set is stored uncompressed Delete a file from the set so that it becomes partially complete Scan the set again Find and Fix. Note that some files should be moved to ToSort Check your RomRoot and notice there are empty directories for sets that were previously partially complete

0

RV should halt if a path is inaccessible

Reproducible

Network File Error

If a path becomes inaccessible during a scan (E.g. mapped network drive), RV will continue to scan and erase information of previously scanned files. Steps to reproduce: Start with a fresh RV instance Map a network drive and assign it as a ToSort. Reproducing this issue works best if the ToSort contains a lot of files and directories. Scan the mapped network drive ToSort After the scan is complete, start the scan again and quickly disconnect the mapped network drive as RV is traversing directories Notice that RomVault will continue the scan without error but will erase any previously scanned info for future directories leaving only empty directory references in the cache.

0

Web links cause a crash if no browser installed

WIP Testing

Crash

If RomVault is used on a system without a web browser, the web links from the UI can cause RV to crash. This occurs with the RomVault docker container that is available in the unraid app repository. Steps to reproduce: Install the RomVault docker container from the Unraid appstore Load RomVault From the help menu, click on "Visit Help Wiki" RomVault will crash with an "EXCEPTION: Source: System Message: Cannot find the specified file" error

0

7z cache grows too large

Need Info

Fixing

With RV 3.7.0 the 7z cache seems to fill up without any deletions. One user reported a 7z cache that grew to over 700 GiB. The files in the 7z cache should be deleted after the archive they are needed for has been written.

2

RV does not handle case sensitive renames with umlaut characters

WIP Testing

Fixing

I found an issue with the new TDC dat and with RV that is causing RV to throw an error: Unexpected file found in directory. Rescan needed. RomRoot\TDC\Games\Files\1994\TÖdliche Gemetzel der MÖrderspinnen, Das (De) (1994)(Ralf zur Linde) [Action].zip I have this file but it is named with lower case ö not Ö, and is already in the correct directory. I suspect the issue is that RV isn't treating ö and Ö as the same when doing case-insensitive (like windows does) and tries to move the file, but as windows is case-insensitive it doesn't change the case and then the RV check fails and throws the error. This is not an issue if the file is in ToSort and RV moves it to RomRoot, only if it is already in RomRoot with the lower case ö. My guess is this would also effect äÄ and üÜ characters. The second part of this issue is that DatVault TDC dat should have the lower case ö, like the original TDC dat. Steps to reproduce: Add the TDC DATs to RV Ensure you have the archive \Games\Files\1994\Tödliche Gemetzel der MÖrderspinnen, Das (De) (1994)(Ralf zur Linde) [Action].zip, and ensure the archive is named with a lowercase ö instead of Ö. Scan the archive in the correct place such that RV would attempt an in-place rename to the correct character case Find and Fix and notice when RV attempts to rename the archive from ö to Ö it throws an error.

0

SAM does not stop gracefully when RV main window is closed

Reproducible

SAM

When compressing files with SAM, and the main window is closed, SAM is also closing (seems that closes without "stopping") and leaving temporary files behind. Steps to reproduce: Open SAM from the RV Help menu Drag and drop an archive onto SAM so it starts restructuring the archive Close the main RV window while SAM is processing Note that SAM does not exit gracefully and a temp file is left over

0

Scroll position of ROM Details Grid resets during a fix

Reproducible

General UX

During a fix, the scroll position of the ROM Details Grid keeps resetting every few seconds which makes it difficult to navigate and view. The scroll position should persist. Steps to Reproduce: Add the Sony PS3 redump DAT and set the rules to use Single Archive without subdirs so that the dat contents are predominately displayed in the rom details grid Start a fix that should take a few minutes to complete (to be able to have enough time to reproduce the issue) Navigate to the PS3 dat in the tree and try to scroll the rom details grid to view set content - notice the grid snaps back to the top every few seconds Try to sort by various columns in the rom details grid - notice the sorting resets every few seconds.

0

Sorting resets during a fix

Reproducible

General UX

When RomVault is fixing, the sort order of the ROM Details and Game List grids keep resetting every few seconds. This behavior makes browsing your collection difficult when a fix is running. The user-specified sort order should persist while a fix is running. Steps to Reproduce: Add the Sony PS3 redump DAT and set the rules to use Single Archive without subdirs so that the dat contents are predominately displayed in the rom details grid Start a fix that should take a few minutes to complete (to be able to have enough time to reproduce the issue) Navigate to the PS3 dat in the tree and try to scroll the rom details grid to view set content - notice the grid snaps back to the top every few seconds Try to sort by various columns in the rom details grid - notice the sorting resets every few seconds.

0

Fixing progress bar does not count "Compress" actions

Reproducible

Minor Bug

The fixing progress bar and percentage indicator do not seem to account for the "Compress" action. Steps to reproduce: Add some zips and a few large uncompressed files to ToSort which are needed for a fix. The issue is easiest to identify if the uncompressed files will be last to be fixed. Scan, Find, Fix Notice that the progress bar and percentage will say 100% before all of the uncompressed files are compressed to their final destination

0

Linux and Windows cache seem to use the same directory separators

Need Info

Core
Linux

copying cache from a windows to linux machine still gives backward slashes. so it seems those are hardcoded

2

Crash occurs when attempting to delete a file open by another process

Reproducible

Crash

RomVault will hard crash during a fix when it attempts to delete a file open by another process. The error is: "The process cannot access the file XXXXX because its being used by another process". When this occurs the cache becomes out of sync with the filesystem and the user must rescan after closing and reopening RomVault. Steps to reproduce: Put a .bin file in your ToSort directory Load a DAT that requires that .bin file Mount the .bin file in Daemon tools so it is locked by that process. Scan, Find, Fix RomVault will crash on the deletion attempt of the .bin file

0

Scanning progress window does not show accurate scanning position

Reproducible

Enhancement

The scanning progress window shows statistics in the upper right corner. This statistic shows the position of the last file scanned in relation to the total number of files in the directory. This is not a useful metric because many files in the directory may already be scanned. Ideally this metric should be: "Number of files scanned including the current file" / "Total files that need to be scanned in the directory" Note in this case "scan" is described as files that need to be hashed because they are either new or their timestamps have changed compared to the RV cache. Steps to reproduce: Start a scan across your RomRoot and ToSort directories on your primary instance of RV Watch the scanning window carefully and note the file progress counter, it is not intuitive to the user and does not appear reflective of what is actually happening

0

CHD verification cannot be cancelled

Reproducible

Enhancement

Cancelling a scan does not stop verification of the current CHD. A scan cancellation should immediately stop the CHD verification process. Steps to reproduce: Place a large CHD file in a ToSort Start a scan of the ToSort Immediately try to stop the scan Notice that RV still continues to decompress and hash the chd and will not cancel the scan until its complete.

0

Crash occurs with “unexpected network error” when a mapped network drive experiences latency

Cannot Reproduce

Network File Error

If a mapped network drive is under heavy load, spun down, or otherwise has excessive latency, then RV will crash during a fix targeting that network drive. Steps to reproduce: Introduce excessive latency to a mapped network drive (Unsure the best way to do this consistently, but the error was observed when there was a heavy network load, it maybe possible to reproduce by disabling your network adapter or unmounting the drive in the middle of the fix) Perform a fix that targets the network drive A crash will occur if the latency is too great Expected behavior: RomVault should display a halting error and update the cache (screenshot)

0

FixDat game description truncated after period character

WIP Testing

Reports

When RV creates a fixdat, it truncates the description value of the game to the last period character. FixDat: Original Dat:

0

Cancel during Find Fixes does nothing

WIP Testing

Enhancement

If you click the cancel button while Find Fixes is running, RV does not actually cancel. The Find Fixes task ultimately completes. The cancel button should either be removed or RV should stop the find fixes task when the user presses cancel.

0

CHDs in archives do not record version flag

Reproducible

Scanning

When CHDs are packed in an archive, the CHD version is not recorded and shows as (CHD ) in the ROM details grid. This also means CHDs will be rehashed every scan if CheckCHDVersion is set to true in the config xml. Steps to reproduce: Add the setting CheckCHDVersion to your config XML and set it to true Download the EmuArc dat for Sega Chihiro from DatVault Set the DAT settings to ZIP Let RV fix the sets so that the CHDs are packed in zip archives Notice the CHD version tag is blank Scan the Chihiro collection again and notice that the archive contents are rehashed due to the missing CHD version

0

DatVault path2 value cannot be null

Cannot Reproduce

DATVault

A user running RV in an ARM Windows VM on a Mac reported that DatVault throws an error whenever a DV DAT update is triggered. The error occurs once the progress bar reaches 100%.

1

Headered roms do not use ZipMove

Reproducible

Fixing

As of RV 3.7.0, headered roms are not zipmoved in scenarios where they could be. Any movements within the RomRoot, or from ToSort to RomRoot do not use ZipMove. Any movement from RomRoot to ToSort does use ZipMove properly. Note this does not appear to be related to matching on Alt hashes. Recent No-Intro headered DATs contain the full hashes of the headered ROMs. Example of a ROM that was not ZipMoved from the headered NES set. Steps to reproduce: Add the No-Intro headered DAT to your DATRoot Scan find and fix some NES headered ROMs so are moved into place according to the DAT Move the DAT to a new location in your DATRoot and update dats to register the location move Find and Fix and notice the the NES headered roms are not ZipMoved, instead they are copied and deleted.

0

Silent crash while navigating during a fix

Cannot Reproduce

Crash

RV will sometimes silently crash when navigating around the UI during a fix. This most commonly occurs with interactions with the Game List grid when drilling in and backing out of directories using the double click left/right navigation. RV does not show any error or crash report, but you can see crash info in Windows Event Viewer.

1

Debug Logging missing detailed fix info for files

Reproducible

Minor Bug

As of RV 3.7.0 the debug log only contains info about which DAT rule is used. There is no detailed info about the fix. Steps to reproduce: Open RV 3.7.0+ Enable debug logging Place some uncompressed roms in ToSort Setup a DAT rule with the archive type set to "File". This dat should contain some of the roms in your ToSort Do a fix Check the debug log in the logs directory and notice it only shows DAT rules processed and there is no info about any fixes.

0

ROM Occurrence list shows orphaned NotGot reference

Cannot Reproduce

Minor Bug

The ROM Occurrence list shows an extra NotGot entry with no path

0

SAM returns CorruptZip errors with Directories input and Zip-ZSTD output

WIP Testing

SAM

SAM returns CorruptZip errors with Directories input and Zip-ZSTD output Steps to reproduce: Change SAM to have Input: Directories, and Output: Zip-ZSTD Drag and drop one or many directories onto SAM for processing Notice the status log shows CorruptZip and an archive is not created

0

Fix DATs contain <dir> tags under <game> with File archive type

Reproducible

Reports

RV alters the format of the FixDAT depending on the user's DAT settings. When the archive type is set to file, any paths in tags are converted to which creates a DAT that has malformed information which is skipped in RV's DAT processing logic. Steps to reproduce: Download the Dats.site PS4 Scene 2023 DAT with DatVault Save a fixdat of that dat from the tree Load the fixdat into RV Filter by "Black" Compare the fixdat to the original dat, you will notice the fixdat is missing a file that was never processed by RV. Example Fix DAT with archive type set to Zip, notice the full path including the Proof folder: Same Fix DAT with archive type set to File, notice the with a within it: The impact is that "game > dir > rom" is invalid and not processed: Whereas the first Fix DAT is proper and RV can see this file in the DAT: Example of problematic FixDAT structure:

0

Description and Name values are not cleansed when used for directories

Reproducible

Logic Issue

The description and name values in the DAT can sometimes have slashes in the value. When RV processes this with single archive settings or auto-directory naming it interprets the slashes as path separators and creates an unwanted sub-directory. Instead, RV should cleanse this value to a proper directory name. Steps to reproduce: Place two dats in a single directory in your datroot. Modify the name value of one of the dats in a text editor to add a forward slash somewhere in the name Update dats Notice that the forward slash is properly converted to a dash in the dat name, but this is not used for the single archive path

0

Single Archive DAT processing options crash with SuperDATs

Reproducible

Crash

The Single Archive DAT processing options can crash RomVault with an "Unable to cast object of type" error. Steps to reproduce: Add the TOSEC-Rollback dat from DatVault Change the DAT settings to Single Archive + Use subdirs for all sets Save the dat rule and notice RV crashes Example DAT Rule RomVault\Various\Rollbacks\TOSEC Zip false None KeepAll Optional false true KeepAllSubDirs false true false false

0

Value of "X" is not valid for "Value" error

Need Info

Minor Bug

While fixing, RV can error when browsing the sets that are actively being fixed. The error appears to be related to a scrollbar value. When the error occurs the fix will continue and the error can be dismissed.

1

RomVault exits when using torrentzip and it it runs out of disk space

Open

Open TorrentZip from the "Help" menu Torrentzip a large file The disk its writing to runs out of space while torrentzipping Whole program just exists .. no exception is caught/logged.

0

The "Only Keep Complete Sets" setting does not work properly on Linux

Reproducible

Fixing
Linux

The "Only Keep Complete Sets" setting does not apply correctly when using Linux with mono: Steps to Reproduce: Select the last folder in a tree and choose the "Only Keep Complete Sets" option (o a not complete set). Place some files that match some of the files in the folder but don't form a complete set into the ToSort directory. For example, add only the .cue file but not the .bin file. Find fixes. RonVault will mark some ROMs as missing and partially fix the sets in the directory. However, there is a workaround to address this issue. After marking the folder, select the parent folder with the same option, and then it seems to work correctly.

0

Crash/Exit when trying to create directory on un-mounted drive

Need Info

I use removable drives .. sometimes ill accidentally scan a dir that is not mounted .. looks like RV just needs a few extra little checks before trying to create a directory on an un-reachable drive. EXCEPTION: Source: mscorlib Message: Could not find a part of the path '\\?\L:\Handheld\Sony - PlayStation Portable'.STACK TRACE: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.Directory.InternalCreateDirectory(String fullPath, String path, Object dirSecurityObj, Boolean checkHost) at System.IO.Directory.InternalCreateDirectoryHelper(String path, Boolean checkHost) at RomVaultCore.FixFile.Util.FixFileUtils.CheckCreateDirectories(RvFile file) at RomVaultCore.FixFile.Util.FixFileUtils.CheckCreateDirectories(RvFile file) at RomVaultCore.FixFile.Util.FixFileUtils.CheckCreateDirectories(RvFile file) at RomVaultCore.FixFile.FixAZip.FixZip(RvFile fixZip, List`1 fileProcessQueue, Int32& totalFixed, String& errorMessage) at RomVaultCore.FixFile.Fix.FixBase(RvFile child, Boolean thisSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixDir(RvFile dir, Boolean lastSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixBase(RvFile child, Boolean thisSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixDir(RvFile dir, Boolean lastSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixBase(RvFile child, Boolean thisSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixDir(RvFile dir, Boolean lastSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixBase(RvFile child, Boolean thisSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixDir(RvFile dir, Boolean lastSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixBase(RvFile child, Boolean thisSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.FixDir(RvFile dir, Boolean lastSelected, List`1 fileProcessQueue, Int32& totalFixed, Int32& reportedFixed, Stopwatch cacheSaveTimer) at RomVaultCore.FixFile.Fix.PerformFixes(ThreadWorker thWrk)

1

ZipMove while file is open results in "Check File Move Error"

Reproducible

Fixing

If an archive is open while RomVault attempts to ZipMove it, an error will trigger and stop the fix. The error states: "Check File Move Error with FileSystemError". Steps to reproduce: Place a complete archive in a ToSort directory that is needed for a fix Keep the archive open, for example within 7zip file manager Find fixes, Fix ROMs RomVault will error when attempting to ZipMove Expected Behavior: RomVault should mark the archive as locked (blue status) and proceed with the rest of the fixes

0

Silent crash under heavy activity

Closed

Crash

RomVault will sometimes silently crash with no error. This seems to occur most frequently when RomVault is scanning / fixing ROMs and you are also navigating around the UI. Most recently I encountered this error while scanning a 25gb ISO and navigating the MAME set with artwork enabled. The windows event viewer showed the following errors: Application: ROMVault3.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr) at System.Windows.Forms.NativeWindow.DefWndProc(System.Windows.Forms.Message ByRef) at System.Windows.Forms.ToolTip.WndProc(System.Windows.Forms.Message ByRef) at System.Windows.Forms.ToolTip+ToolTipNativeWindow.WndProc(System.Windows.Forms.Message ByRef) at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr) at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef) at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32) at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext) at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext) at ROMVault.Program.Main() And a few seconds later this error occurred: Faulting application name: ROMVault3.exe, version: 1.0.0.0, time stamp: 0x642596db Faulting module name: comctl32.dll, version: 5.82.19041.1110, time stamp: 0x3e15b9f6 Exception code: 0xc0000005 Fault offset: 0x000000000003d300 Faulting process id: 0x118b0 Faulting application start time: 0x01d96b5d42b97c39 Faulting application path: C:\Emulation\ROMVault3\ROMVault3.exe Faulting module path: C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.19041.1110_none_792d1c772443f647\comctl32.dll Report Id: 43417e29-a0a0-44fd-a6e6-1d310d3e7d0d Faulting package full name: Faulting package-relative application ID:

0

Incorrect "Scanning Dirs" percentage in window title when scanning

Reproducible

Minor Bug

When I scan my "To Scan" directory the window title of the progress dialog shows "Scanning Dirs - 100% complete". But it just started, it is not 100% complete and therefore confusion when looking at the title in the Windows taskbar it would help if I see values like 75% or 90%. Or no percentage value. It is for sure a minor, more or less cosmetic bug... Suggested solutions (if I did not misunderstood the intention): 1) Just show "Scanning Dirs" or "Scanning Dirs - in progress..." 2) Update the title with the correct percentage value each time the value increases 3) Show instead the current dir name that is currently scanned, e.g. "Scanning dir: To Sort" with a relative (short) path that might work... Steps to reproduce: Scan a ToSort directory with many subdirs Notice as its scanning the title bar says 100% complete

0

Odd Behavior

Need Info

Appears to be UN-zipping and re-zipping same large zip file, in fix rom mode. No Dat... Folder was added as an unlocked to-sort directory on a separate drive. File is large zip with folders containing smaller zips. Possibly converting file from zip to 7z? If so, it is doing this unprompted and on a separate drive/folder than the set RomRoot folder.

1

Matches are deleted when a drive is disconnected

Closed

Scanning

I have 11 drives and so sometimes a drive becomes disconnected temporarily (until I restart Windows). If I scan my dats during this time everything is marked as missing again which is annoying for large datasets. If the drive is missing, not just the folder, I would prefer for RomVault to yell at me or even just ask if I really want to scan these dats at this time instead of forcing me to rescan later. Some collections are very large and take hours or days to completely rescan, like Redump or TOSEC-ISO.

1

Long paths can result in a crash during a fix

Need Info

Crash

(screenshot)

0

An "Unable to cast object of type" error can occur with certain directory settings

Closed

Logic Issue

When certain directory settings are used, an "Unable to cast object of type" error can occur. Steps to reproduce: Start with a clean RomVault instance Place the Mamma MIA DatVault DATs into your DATRoot using Master Directories and Subdirectories Change the directory settings of the RomRoot as shown in screenshot #2 Apply settings Close the window so the DATs are reprocessed An error will occur Expected behavior: RomVault should not throw a crash-like error If the directory settings are incompatible then a friendly error should display (screenshot 1, 2)

1

If a fix only consists of removals to ToSort, the percentage complete and progress bar stay at 0%

Reproducible

Enhancement

Steps to reproduce: Start with a fresh RV instance Place some files that do not match any dat in your romroot Scan files Find and fix Notice the progress percentage does not update for any removals to ToSort

0

Browsing subfolders in a ToSort during a scan/fix will change the DAT Info panel back to the root of the ToSort every few seconds

Reproducible

Enhancement

Steps to Reproduce: Start a scan Navigate a ToSort by drilling into directories in the Game List grid Notice the DAT info panel reverts back to the root ToSort directory every few seconds instead of showing the info about the directory you are currently viewing

0

Crash occurs when RV tries to do a fix from a path that is no longer accessible due to a case sensitivity difference

Need Info

Case Sensitivity Issue

In general Windows is not case sensitive, but users can have setups with SMB shares that are case sensitive. This can result in situations where a path is inaccessible or its contents unexpected due to case sensitivity differences. Steps to reproduce: See discord for details: https://discord.com/channels/619198661838241795/870048528112697344/992569737995370546 If the information in Discord is not sufficient, contact johnsanc Expected behavior: Handle case sensitivity conflicts gracefully with a halting error and cache update (screenshot 1, 2)

1

Crash occurs when trying to write a file that is only a case sensitive rename

Need Info

Crash

(screenshot)

0

An “Unexpected file found in directory” error can occur when ZipMoving a complete archive from ToSort to RomRoot when multiple dats are mapped to the same directory in the RomRoot

Need Info

Logic Issue

(screenshot)

0

A vague error can occur when there are unscanned files using File archive type in your RomRoot and a fix tries to move files of the same name into place

Reproducible

Enhancement

The error message is not intuitive, this should trigger an “Unexpected file found” error instead. The error message should be descriptive and tell the user why there was an error. In this case its because there was an unknown file by the same name in the destination directory. Steps to reproduce: Start with a new RV instance Add the Wii U WUX dat to your datroot and change the DAT rule to use single archive with no subdirs Place a WUX file with the correct name in your ToSort Place another copy of the same file in the correct location in your romroot Scan ONLY the ToSort Select both the ToSort and the DAT and do Find and Fix When RV tries to move the WUX file from ToSort to the proper location it cannot since theres already a file with that name in that location. Notice the vague error that displays that does not tell the user what the root cause of the issue was.

0

A fix can end early and look complete under certain conditions, but fixes still remain

Need Info

Logic Issue

Sometimes a fix can end early and look complete, however the percentage is not 100%. This also results in a state where RV appears to show fix sources (orange/brown) still available. Finding fixes again will show the corresponding yellow fix statuses. Steps to reproduce: Cannot reproduce the issue and unsure what conditions led to this. Occurred on 7/14/22 using the latest WIP build at that time. Expected behavior: All fixes should be completed in a single Fix run. (screenshot 1 | screenshot 2 | screenshot 3)

1

Powered by Convas