Santiago González

I got a working example. Attached database has empty master key (if you wish you can also create the database yourself, as it is default database). In "Sample Entry" add "Test" field with this value (multiple lines): ¿ 0 In "Sample Entry #2" add "Test" field with this value (multiple lines): ? a Don't save the database. Perform XML Replace: Select nodes: //Entry/String[starts-with(Key,'Test')]/Value Action: Replace data Data: Inner text Find what: androidapp://org.mozilla.firefox_beta Replace with:...

XML Replace crashes when "Find what" and "Replace what" are empty

Also, it's for KeePass 2.x, not 1.x. I can't edit my post, but the modified entries indicate "..." (three dots) in the Modified column instead of ".." (two dots). Use the screenshot as the source of truth

Sorry for the late reply. I left this undone until now that I'm trying to apply XML Replace again. I don't know why these entries are different, but they are marked as modified even though their contents remain unchanged. The same entries are modified for every XML Replace I tried. You can also see: https://sourceforge.net/p/keepass/feature-requests/2990/ There I tried another XML Replace I want to do. Btw, tysm for your help here. Your approach did work, but KeePass behavior makes me avoid to use...

Hi, May I ask whether you were already aware of this behavior before my report, or is this the first time you've seen it? Also, if I provide a database that reliably reproduces the issue, would you be willing to investigate and potentially fix it? At the moment, I'm hesitant to use XML Replace because this behavior makes me question the integrity of the data. If entries can be marked as modified even when no visible changes are made, I'm concerned there could be other unintended side effects that...

XML Replace Marks Entries as Modified Even When No Actual Changes Are Made

Thanks for the feedback. I agree that RFC6238 recommends tolerance windows and that many implementations are forgiving in practice. However, the RFC recommendation is not mandatory, and real-world implementations vary. Some services appear to accept only the currently valid code or behave more strictly near the boundary of a time step (whether by implementation choice, clock skew handling, or simply imperfect implementations). In my own experience, I have encountered this with at least some government...

Allow TIMEOTP placeholder to generate the next TOTP when close to expiration