ErrorTimeStamp can occur when file has not changed

Open

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

Unique files can be deleted due to alt hash matching

Reproducible / In Progress

Logic Issue

setup both the regular and dir2dat rollback dats each in their own folders, then setup RV to use the same destination folder. Dats are: MAME 0.257 Rollback CHDs MAME 0.257 Rollback CHDs (dir2dat) place a copy of the following problematic chd files in the tosort: MAME (v0.145) - csplayh5 csplayh5.chd 204,128,041 bytes V4 CHD external sha1 hash: 462f0884b8cf8566e86b17f1dfd670fbc2bf3a31 internal sha1 hash: ce4883ce1351ce5299e41bfbd9a5ae8078b82b8c MAME (v0.254) - csplayh5 csplayh5.chd 203,229,077 bytes V5 CHD external sha1 hash: 43d8f5071a4e1a0d5758767114f62afa316c369f internal sha1 hash: ce4883ce1351ce5299e41bfbd9a5ae8078b82b8c NOTE: the internal hash is identical for both chd's. Do a L3 (full scan) of those 2 CHD's in the tosort so the internal hashes are stored in the AltSHA1 column. run FIND FIXES and note the matches found for each dat: a) "MAME 0.257 Rollback CHDs" dat: we get 2 matches for each of 0.145 and 0.254 entries. This dat is matching both files based on the INTERNAL SHA1 hash and since the internal hash is identical, we will get 2 copies of the same file. b) "MAME 0.257 Rollback CHDs (dir2dat)" dat: we get two matches here too, but the dat is matching based on the EXTERNAL hash of the files. The v0.145 entry is the V4 CHD, and the 0.254 entry is the V5 CHD, so we will get two different filesizes in this folder. Run FIX FILES and note the following: a) the "MAME 0.257 Rollback CHDs" dat gets processed first as it is first in the list alphabetically. It is matching based on internal SHA1, so: - 1st action is to MOVE the csplayh5.chd (0.145, filesize 204,128,041 bytes) into the romroot folder - 2nd action is to make a copy of the 0.145 CHD as the 0.254 CHD (same filesize of 204,128,041 bytes). These are the only 2 actions on this dat, so this dat is now finished. We now have two identical copies of the V4 CHD in two folders. RV now moves on to process the 2nd dat. b) the "MAME 0.257 Rollback CHDs (dir2dat)" starts its rebuild and as noted before, it is matching CHD's based on the EXTERNAL file hash. RV tries to rebuild the first entry which is the csplayh5.chd with a filesize of 204,128,041. BUT WAIT.. that file already exists in the destination folder since we just rebuilt it! RV errors with a "Rescan needed, File Changed" on that file and rebuilding halts. Close out the error and the scan window. We now have 2 identical CHD's in the "MAME 0.257 Rollback CHDs" folder, and nothing in the "MAME 0.257 Rollback CHDs (dir2dat)" folder. The ToSort folder still has the 0.254 V5 CHD (203,229,077 bytes) in it. RV is confused right now and wants us to rescan the datroot so it can confirm where those files are. Right-click on the top of the romroot tree ("RomVault") and do a SCAN FULL (L3). RV now knows where the CHD's are. Remember the results of step #7? In the "MAME 0.257 Rollback CHDs (dir2dat)", which was previously empty, it now finds the V4 CHD and marks it green. But now it can't find the V5 CHD.. but we know it is in the ToSort folder. Run a FIND FIXES. Now, this is where things get interesting.. noticed what happened? In the "MAME 0.257 Rollback CHDs (dir2dat)" dat, RV has now matched the V5 ROM (203,229,077 bytes) which is sitting in the ToSort, but NOW WANTS TO DELETE THE V4 (204,128,041) CHD from the folder, since it doesn't exist in this dat!! But that V4 CHD belongs to the "MAME 0.257 Rollback CHDs" dat. You should now guess what will start to happen.. but go ahead and run a FIX FILES. a) RV straight up deletes the V4 CHD (204,128,041 bytes) from the 0.254 CHD folder, then b) moves the V5 CHD (203,229,077 bytes) from the ToSort into the 0.254 CHD folder. Wait now.. RomVault says everything is green now! Sweet. BUT.... when you look in the rom folder, there is only one copy of each CHD.. MAME (v0.145) - csplayh5 (V5 CHD, 204,128,041 bytes) MAME (v0.254) - csplayh5 (V4 CHD, 203,229,077 bytes) Right-click on "RomVault" in your dat tree and select "Scan Full" again. Yep.. now the "MAME 0.257 Rollback CHDs" dat is missing a CHD. vvvvvvvvvvv BUG STARTS HERE vvvvvvvvvvv Run FIND FIXES. OK.. it can fix the issue, but when you do, it now OUTRIGHT DELETES the (V4 CHD, 203,229,077 bytes) CHD!!!!!!!!!!!! Go check the rom folder.. it's GONE. WHAT DA FUK!! But RV once again says all 4 CHD's between both dats are GREEN. Let's do one more right-click on the RomVault datroot and do a "Scan Full". Oh no.. the 0.254 CHD is now off the list and no longer green.. because RV deleted it. Now RV is reporting in the "MAME 0.257 Rollback CHDs (dir2dat)" folder that the 0.254 V4 CHD is missing. It's toast. I hope you kept a copy of it, or go download it again from the PD torrent :) All that is left in the destination folder is two folders, MAME (v0.145) - csplayh5 (containing the V5 CHD, 204,128,041 bytes) MAME (v0.254) - csplayh5 (folder is now empty)

0

Powered by Convas