File order is broken

[SoyRA]

Basically what I put in The Checksum doesn't respect my "View Settings", but in short this is what happens:

• If you have your folder sorted by Type and you create a Checksum: on the HDD it will remain in the same order while on the SSD it won't (HDD-Example.gif - SSD-Example.gif).
  • It doesn't matter if it's by Type, Name, etc. the point is that the order will be different if you do it on an SSD.

But this problem doesn't occur when doing this:

• Right click -> Properties -> Checksum
• Right click -> Properties -> Checksum -> Save . . .

[tERyceNzAchE]

Based on your referenced issue, this has been the way the original HashCheck fork has handled things from it's creation. I would not label this as a bug, and instead consider this an enhancement.

[SoyRA]

- Write: everything I said, I think it's like this to make it faster.
- Read: On the HDD it reads ordered while on the SSD it reads unordered (it doesn't matter if the file was generated ordered or not).

And I also noticed that it doesn't sort well either (or at least not respecting the folder structure) in the verification, for example:
- Sort by Name: Perfect, I'll see "FileA -> FileB -> FolderA\File1 -> FolderA\File2 -> FolderB\File1". :P
- Sort by Status: Well...it does, but now the names are unordered (unlike how it's done by Name).
* For a few files it doesn't bother, but when there are many...it becomes complicated. @,@

[idrassi]

Please check my explainations on the issue #15

Basically, the cause is the use of multithreading in case of SSD to speedup computation.
I have proposed to sort the entried of the checksum file after all computations are done. The sort will be based on lexicographical order on name. This will not always match the Explorer View Settings (I don't know how to read that programmatically) but it is better than nothing.