megaT, on 25 May 2023 - 03:41 PM, said:
so the file will be tried and rehashed if it was copied to the new windows installation.
But nothing is copied anywhere...
Anyway, if it helps, imagine the setup this way:
Disk ---> nth number of partitions
x partition holds Windows XP 32-bit
y partition holds Windows 7 64-bit
z partition holds eMule folders (this includes the eMule exe, config, log, etc directories as well as incoming and shared folders)
z partition has a letter, and the letter is the same to both Windows installation.
But still, I don't understand why check the date.
I actually understand it as, instead to check the whole file hash each time eMule runs, it checks if it has been modified and then reshases it.
But, also, I don't find any circumstance under a shared/downloaded file is modified unless, maybe with a archive file (rar, zip, etc), or an office document (xls, doc, etc, that auto-rewrites on opening as backup)?
That aside, isn't the UTC time the same on both systems?. I'll check where is the difference, because DST shouldn't be the problem, I think..., and the timezone is also the same, but if we are talking about UTC, again, it doesn't matter... the offset.
I'm lost of why any of the above is a problem here XD
Did I just find a bug by mistake?
By the way, I used a virtual machine to run a Windows 7 32-bit and... the same eMule, the same letter the same config, and the same problem with
known2_64.met. It brought the same error and started rehashing everything:
[time and date] AICH Hashset to write should be already present in known2.met [file hash here]
So, the architecture is not the problem :S
And as I understand by the help files on the page, the reference to known2.met in the error message is legacy, if now is being used known2_64.met.
This post has been edited by squidlogic: 25 May 2023 - 09:24 PM