Shawn

You're not modifying an entry. You're copying it somewhere else, and likely to a different database. So it's similar to an Export (both commands are in the 'Data Exchange' section). For a modified copy, you can use 'Duplicate Entry' instead. That one is designed to be modified, because it gets a new name by default and you can also discard the history in the process. So for 'Duplicate Entry' discarding the creation time makes more sense (it's still debatable). Also, 'Creation time' can be considered...

I think this behavior is wrong, because: The creation time can be important. It shouldn't be discarded without asking the user. It makes no sense for the creation time to be more recent than the last modification time. It's inconsistent with the 'Data Exchange: Export' behavior. If you Export > Import an entry, the original creation time is preserved, even if it the UUID is different. I see 'Data Exchange: Copy > Paste' as an alternative to 'Export > Import' to move entries between databases. In...

Go to Entry > Data Exchange > Copy Entry (encrypted or unencrypted) Paste Entry The Creation Time is not preserved. The pasted entry gets a new Created date and time.

I have read that and also every other post here. The reason I nevertheless posted here is because those arguments are not convincing or they are too vague. "Performance" - see above. "Not usable if all fields are encrypted and replaced by asterisks" - this is a silly strawman argument. Nobody is suggesting that all fields would or should be encrypted. I even said keep it disabled for non-passwords by default, just like in 2.17. "Users get confused" - vague, debatable. And this can be improved by...

I installed version 2.17 to see what the performance impact looks like on an almost 10 years old PC. I enabled encryption for Notes (it's in the database settings), created a handful of entries and then typed or pasted text in them. When typing or pasting a few sentences, the performance impact was not noticeable. The impact only became obvious when pasting large amounts of text, like from a ~50kB text file. There was increased CPU usage and some delay when saving and opening individual entries....

I would also like to have more than 2GB available. It makes no sense to limit it. If I understand this post correctly, the limit exists because of the compatibility with .NET 2.0. Well, that was 10 years ago, does KeePass still depend on .NET 2.0 now? @dreichl @emilia98: Also KeePassXC does not have a 2 GB limit for Argon2. True. And if you save a database with more than 2GB in KeePassXC, it doesn't open in KeePass, which is quite unfortunate. @pail459 1GB and a good password is all you ever need....