I’ve just upgraded to v.13, but this has been the same with v.12. For some reason unknown to me, one of my folders never reports percentage progress while scanning - see screenshot. What might be the problem? Is it the size? Or is it more like “Scanning” without percentage means scanning for changes - in other words browsing through 180k files to see if there is something to index, while "Scanning (xy%) really means indexing?
and details:
Ok, so I think I was right. After watching closely it now shows percentage as well and indexing new files. The reason I missed that was that it takes quite some time to scan due to the size but indexing is quick because only a few mods are done at a time.
So, wouldn’t it be better to actually indicate Scanning (%) as a scanning for change and Indexing (%) as hashing changes?
Exactly this. It doesn’t have anything to base a completion percentage on until it knows which files need to be rehashed, so the first part of it (looking for changed files) is percentage-less. If no files were changed, it’s done after that step. Otherwise, it starts hashing changed files and you’ll see the completion percentage, estimated time remaining, etc.
Ok 
Well, for scanning surely you somehow “browse through” last known (local/global/something) quantity of files to search for changes right? Or does it just recursively browse from root folder not knowing what to expect? My point is that if there are 180k files and 20k folders surely you should be able to calculate the process of scanning when you just search for changes against database.
In my view, this should be called scanning, and what is called scanning should be indexing. Or do you have a different view?
Even if we know that we’re going to look through 180k files (which we do), what percentage should we show? We could count up from 0 to 100% during this phase, but then reset back to zero at the next phase? Or from 0 to 50% and then in most cases jump directly to 100%? If you’ve deleted 100k files we’ll increment some percentage for the first 80k files that we see, then jump to the end state?
I think most of these don’t make sense, and in most cases the initial scan-for-changes takes seconds, while the actual hashing step can take minutes or hours depending. The percentage is more useful in the second phase, in my opinion.
I could see an argument for it being a different state from Scanning if you like (Preparing Scan maybe). Or the first phase is Scanning (no percentage) and the next phase is Hashing (0-100%)… But that assumes it will always be two phases, which is something I’d like to get rid of in the long term.
(There’s also a third phase after the hashing where we specifically check for removed files…)
Well, I’m really not too concerned because now I know the difference. I understand what you’re saying but I think there should be two phases. Hmm, I see your update regarding eliminating phases.
All I can say that in large repos - 200k files - it shows scanning for quite some time. Until now I wasn’t even sure if it was doing something or not but eventually it went away.
Another case is where we “know” there are 180k files, but you’ve just added another 100k. Our percentage would then as well be unknown.
I’m open for improvements here, but it’s not clear to me that this is trivial to solve as we don’t know how much work we have to do until we’ve done it, basically.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.