I apologize if this is an obvious question, but I'm going to ask it anyways... I'm trying to understand, what exactly happens in a fastscan operation? I've read that it basically does that same thing as a scan, but instead operates on the incorrect files generated from a full scan. But it seems to be doing more than just that. For instance, take a set that has scanned cleanly and is perfect. For this set the list of incorrect files is presumably empty. Now, if I mess with any of the files in the set (rename it, duplicate it, etc) and run a fastscan, the fastscan detects it and corrects it!

Now of course I'm not complaining- it's great that it can fix those problems. I'm just trying to understand, when exactly to I ever need to run a full scan? Is it only when scanning for the first time with a datfile, and thereafter I should always use a fastscan? Or is there something else that I'm missing. I'm tempted to just always run fastscans because they are so fast, but I want to make sure that the fastscan isn't missing some critical error that would be caught with a full scan. Do those conditions exist?

Any advice would be much appreciated.

(On a side note, this is an excellent program- I'm always surprised at how fast it runs. You must be using some very fast hashing functions and a lot of disk caching or something like that? If you want to shed some light on how you perform these operations on so many files so quickly, I'd love to know...)

> (On a side note, this is an excellent program- I'm always surprised at how fast
> it runs. You must be using some very fast hashing functions and a lot of disk
> caching or something like that? If you want to shed some light on how you
> perform these operations on so many files so quickly, I'd love to know...)
>

A note about the context of this particular comment- something like torrentzip takes ages to scan through many files, even if they are already torrentzip'd (skipped files). I suspect that most of that slowdown is due to I/O (they print out a message to stdout and to a log file for every file!), and I'd like to look at the source to see if it can be sped up. Just curious if you had some special tricks...

A fastscan scans only the sets which were listed with issues in a previous scan. The used scan options are restored as well, but you can enable/disable fix operations if you like.


Roman Scherzer

There is no real magic behind it...well....in fact I can still optimize the speed a lot if I find the time for a rewrite.


Roman Scherzer

> A fastscan scans only the sets which were listed with issues in a previous scan.

This statement seems incorrect to me? My point was that when fastscanning a set with ZERO roms listed with issues from the previous scan, and I alter a rom (break its name), the fastscan detects that and fixes it. So the scanner is looking at roms that were NOT listed as having issues.

> This statement seems incorrect to me? My point was that when fastscanning a set
> with ZERO roms listed with issues from the previous scan, and I alter a rom
> (break its name), the fastscan detects that and fixes it. So the scanner is
> looking at roms that were NOT listed as having issues.
>


If check set + name / unneeded was enabled, this check is of course done in the fastscan as well and it detects your change.


Roman Scherzer

> If check set + name / unneeded was enabled, this check is of course done in the
> fastscan as well and it detects your change.

Aha, OK. So I just have two more questions:

1. So is it correct to say that the check/fix boxes apply to ALL sets, not just those marked as having problems?

2. If I check all the boxes (missing, case, unneeded, name, size, date, checksums), and run a fastscan, what is an example of a problem that the fastscan will miss?

> 1. So is it correct to say that the check/fix boxes apply to ALL sets, not just
> those marked as having problems?

No.

Fastscan does nothing special. It simply does (and in fact it's the same routine) a scan but it skips sets which aren't listed in a previous scan. It will reset the options which were selected in that last 'full' scan. Exception: You are able to enable/disable the fix options.
So fastscn IS limited to the sets which had issues in the last (depending on the selected merge mode this may include clones/parents as well).

Set + unneeded/name check is somehow special since it doesn't work on the single archives themselves but on all files in romfolders. If the options were enabled in the full scan, they get reenabled and the check is redone.

That's why a changed setname is detected. If you remove a file from a set which wasn't listed before, the fastscan won't bring it up.

Fastscans can be done until the loaded data has changed (e.g. when MAME was updated).


Roman Scherzer

> > 1. So is it correct to say that the check/fix boxes apply to ALL sets, not
> just
> > those marked as having problems?
>
> No.
>
> Fastscan does nothing special. It simply does (and in fact it's the same
> routine) a scan but it skips sets which aren't listed in a previous scan. It
> will reset the options which were selected in that last 'full' scan. Exception:
> You are able to enable/disable the fix options.
> So fastscn IS limited to the sets which had issues in the last (depending on the
> selected merge mode this may include clones/parents as well).
>
> Set + unneeded/name check is somehow special since it doesn't work on the single
> archives themselves but on all files in romfolders. If the options were enabled
> in the full scan, they get reenabled and the check is redone.
>
> That's why a changed setname is detected. If you remove a file from a set which
> wasn't listed before, the fastscan won't bring it up.
>
> Fastscans can be done until the loaded data has changed (e.g. when MAME was
> updated).
>
>
> Roman Scherzer
>

Thank you Roman! I've got it now.