First let me express how grateful I am for your keeweb application, and the time you took to create it. I understand you may not respond, but I figured I'd just have to try.
I've been a recent "victim" of the Error: too large number bug. At first it was only when trying to sync my file via WebDav to Nextcloud (and at the time I blamed Nextcloud), but now I also can't open it either.
Dabbling in TS I cloned the repo and found the root cause of the error. As indicated in the original issue, KeePassDX on Android does something weird with some date values.
In my case it was the "LastModificationTime" value in the CustomData dictionary, that has the value JoU/Fe4cIAA=. After fiddling around the kotlin code, that gave me a date on year 286,428,884 which is close to the maximal value in Joda-Time, but very very far above the maximal value for JS Date(), which year 275,760. So, even if the code didn't throw on such high value, we still would have an Invalid Date in the end.
So on how to fix this? I see two separate ways.
Consider those values as garbage
When encountering those values, getDate() will return the maximum JS value. In all cases, OG KeePass uses .Net DateTime, which doesn't go over year 9999, so that should be more than OK.
Pros:
not a lot to change in the kdbxweb library to make it work.
not reeaally a breaking change for users of the library (like keeweb), as the value is still a Date.
Cons:
that would update LastModificationTime values of things Keeweb didn't change.
the new date may cause problems on merging.
Use BigInt() objects
The above value JoU/Fe4cIAA= is too high to be contained in a Number variable, but fits in the more recently available BigInt type. By allowing getDate() to return either a Date object or a BigInt, the kdbxweb can still handle those high values and does not require to clamp them to a supported Date.
Pros:
that would no longer change LastModificationTime dates upon saving.
merging on those high values is still possible as we can compare BigInt()
Cons:
Breaking change for all dependents on kdbxweb that must handle a BigInt() value in addition to Date()
More work wherever the kdbxweb library handles dates.
What would be your opinion?
I'm willing to do the corresponding work and provide a PR for either chosen solution, including on the keeweb repository too if necessary. My end goal would be that the Nextcloud App could grab an updated version and fix the bug for me on my Nextcloud instance. :)
Hello,
First let me express how grateful I am for your keeweb application, and the time you took to create it. I understand you may not respond, but I figured I'd just have to try.
I've been a recent "victim" of the Error: too large number bug. At first it was only when trying to sync my file via WebDav to Nextcloud (and at the time I blamed Nextcloud), but now I also can't open it either.
Dabbling in TS I cloned the repo and found the root cause of the error. As indicated in the original issue, KeePassDX on Android does something weird with some date values.
In my case it was the "LastModificationTime" value in the CustomData dictionary, that has the value
JoU/Fe4cIAA=. After fiddling around the kotlin code, that gave me a date on year 286,428,884 which is close to the maximal value in Joda-Time, but very very far above the maximal value for JS Date(), which year 275,760. So, even if the code didn't throw on such high value, we still would have an Invalid Date in the end.So on how to fix this? I see two separate ways.
Consider those values as garbage
When encountering those values,
getDate()will return the maximum JS value. In all cases, OG KeePass uses .NetDateTime, which doesn't go over year 9999, so that should be more than OK.Pros:
Date.Cons:
Use BigInt() objects
The above value
JoU/Fe4cIAA=is too high to be contained in aNumbervariable, but fits in the more recently availableBigInttype. By allowinggetDate()to return either aDateobject or aBigInt, the kdbxweb can still handle those high values and does not require to clamp them to a supported Date.Pros:
Cons:
What would be your opinion?
I'm willing to do the corresponding work and provide a PR for either chosen solution, including on the keeweb repository too if necessary. My end goal would be that the Nextcloud App could grab an updated version and fix the bug for me on my Nextcloud instance. :)