regression with v1.2.0 (vs 1.1.4)

[shuther]

I was just comparing 2 files with v1.1.4 and it worked as expected, then I installed the latest version with cargo and I end up with a corrupt database? The files are expected to both work. Replaced package keepass-diff v1.1.4 with keepass-diff v1.2.0 (executable keepass-diff)

RUST_BACKTRACE=1 keepass-diff --same-password "yyy(2024-01-20 180921).kdbx" "xxx.kdbx"

Password for both files: 
thread 'main' panicked at /home/xxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/keepass-diff-1.2.0/src/main.rs:122:18:
Error opening database A: DatabaseIntegrity(Xml(BadEvent { expected: "text containing a value", event: End("Data") }))
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: keepass_diff::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
shuther@ubuntu-vm:/mnt/smb/documents/shuther/nextcloud/Documents/Perso/keepw$ RUST_BACKTRACE=full keepass-diff  --same-password  "xxx-osx (2024-01-20 180921).kdbx" "xxx-osx.kdbx" 
Password for both files: 
thread 'main' panicked at /home/xxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/keepass-diff-1.2.0/src/main.rs:122:18:
Error opening database A: DatabaseIntegrity(Xml(BadEvent { expected: "text containing a value", event: End("Data") }))
stack backtrace:
   0:     0x5580507c8e06 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h410d4c66be4e37f9
   1:     0x5580507e98a0 - core::fmt::write::he40921d4802ce2ac
   2:     0x5580507c6e3f - std::io::Write::write_fmt::h5de5a4e7037c9b20
   3:     0x5580507c8be4 - std::sys_common::backtrace::print::h11c067a88e3bdb22
   4:     0x5580507ca147 - std::panicking::default_hook::{{closure}}::h8c832ecb03fde8ea
   5:     0x5580507c9ea9 - std::panicking::default_hook::h1633e272b4150cf3
   6:     0x5580507ca5d8 - std::panicking::rust_panic_with_hook::hb164d19c0c1e71d4
   7:     0x5580507ca4b2 - std::panicking::begin_panic_handler::{{closure}}::h0369088c533c20e9
   8:     0x5580507c9306 - std::sys_common::backtrace::__rust_end_short_backtrace::hc11d910daf35ac2e
   9:     0x5580507ca204 - rust_begin_unwind
  10:     0x5580506cba15 - core::panicking::panic_fmt::ha6effc2775a0749c
  11:     0x5580506cbe83 - core::result::unwrap_failed::ha188096f98826595
  12:     0x5580506d7082 - keepass_diff::main::h9ae5aec15cd8feea
  13:     0x5580506e7683 - std::sys_common::backtrace::__rust_begin_short_backtrace::h30b910d3657988f1
  14:     0x5580506ea61c - std::rt::lang_start::{{closure}}::hd561d120cee572dd
  15:     0x5580507c22e1 - std::rt::lang_start_internal::h4d236095b69a230b
  16:     0x5580506de0b5 - main
  17:     0x7f1cf992fd90 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  18:     0x7f1cf992fe40 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:392:3
  19:     0x5580506cc145 - _start
  20:                0x0 - <unknown>

If I could see the string or the key I should be able to confirm the date (valid or not); hope it helps

[shuther]

same issue. t``` hread 'main' panicked at /home/shuther/.cargo/registry/src/index.crates.io-6f17d22bba15001f/keepass-diff-1.2.0/src/main.rs:122:18: Error opening database A: DatabaseIntegrity(Xml(BadEvent { expected: "text containing a value", event: End("Data") })) stack backtrace: 0: 0x557214edbe06 - ::fmt::h410d4c66be4e37f9 1: 0x557214efc8a0 - core::fmt::write::he40921d4802ce2ac 2: 0x557214ed9e3f - std::io::Write::write_fmt::h5de5a4e7037c9b20 3: 0x557214edbbe4 - std::sys_common::backtrace::print::h11c067a88e3bdb22 4: 0x557214edd147 - std::panicking::default_hook::{{closure}}::h8c832ecb03fde8ea 5: 0x557214edcea9 - std::panicking::default_hook::h1633e272b4150cf3 6: 0x557214edd5d8 - std::panicking::rust_panic_with_hook::hb164d19c0c1e71d4 7: 0x557214edd4b2 - std::panicking::begin_panic_handler::{{closure}}::h0369088c533c20e9 8: 0x557214edc306 - std::sys_common::backtrace::__rust_end_short_backtrace::hc11d910daf35ac2e 9: 0x557214edd204 - rust_begin_unwind 10: 0x557214ddea15 - core::panicking::panic_fmt::ha6effc2775a0749c 11: 0x557214ddee83 - core::result::unwrap_failed::ha188096f98826595 12: 0x557214dea082 - keepass_diff::main::h9ae5aec15cd8feea 13: 0x557214dfa683 - std::sys_common::backtrace::rust_begin_short_backtrace::h30b910d3657988f1 14: 0x557214dfd61c - std::rt::lang_start::{{closure}}::hd561d120cee572dd 15: 0x557214ed52e1 - std::rt::lang_start_internal::h4d236095b69a230b 16: 0x557214df10b5 - main 17: 0x7fe066bb1d90 - libc_start_call_main at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16 18: 0x7fe066bb1e40 - __libc_start_main_impl at ./csu/../csu/libc-start.c:392:3 19: 0x557214ddf145 - _start 20: 0x0 -

[shuther]

it is working fine with 1.1.3 with: RUSTFLAGS="-C target-cpu=native" cargo install --version 1.1.3 keepass-diff

[Narigo]

Thank you for reporting @shuther and sorry for checking back here so late!

If I remember correctly, there have been some bigger updates to the underlying lib between 1.1.x and 1.2.0. Looking at the error message, it sounds like there are issues parsing the database file. I suspect that either the regular client you're working with is saving the database in some strange way or the keepass-rs library is not capable of parsing something that you're saving in your database. Maybe storing files or notes or something else in the database? I mean, maybe some feature that is not being used in the current tests could create this. Since it worked previously it sounds more like a regression to me, but I don't know the keepass specification and never worked on the low level there 😬

In general, it would be very helpful to have a reproducer - you might be able to create one based on your currently not working database. Workflow would be to copy it, remove entries until I find the one that causes the issue, then check what this entry has that others don't, then create a new database with just that and check if it's still problematic. I know this could be tedious and long, but it would be a good addition to the existing tests. Most probably, there has been a new release for keepass-rs though and it may have fixed this issue already. Checking this would be to update the dependency in our Cargo.toml, build it with the newer version of the dependency and hope that it already works. If it still doesn't, we need to open an issue against keepass-rs.

[shuther]

So I took my original file, I emptied it completely and deleted the recycle bin (within keepass-xc) and I still face the issue. What is strange is the size of this new file; even save as backup from keepass-xc is generating a file as big as the original one and I can't find a compact option somewhere. Would you know where to submit these different issues ?

[shuther]

linked to issue

[Narigo]

Never saw that...! Did you save the file and closed keepass-xc after doing this? Are you sure no process is still keeping the file open so it doesn't actually change after saving it with new contents?

[shuther]

I think I identified the problem while going through the xml. I have Items with proper dates in but with different format. I am not sure if it is expected (from Keepassxc) or not; and where should it be fixed (for read, and for write). Maybe keepass-diff should ignore this section?

            <Item>
                <Key>_LAST_MODIFIED</Key>
                <Value>Thu Jun 20 13:10:15 2024 GMT</Value>
            </Item>
            <Item>
                <Key>_CREATED_xxxst</Key>
                <Value>11-Sep-22 15:59</Value>
                <LastModificationTime>suCv2g4AAAA=</LastModificationTime>
            </Item>
        <Item>
                <Key>_CREATED_chrome laptop</Key>
                <Value>07/03/2023 11:34</Value>
                <LastModificationTime>KQqZ2w4AAAA=</LastModificationTime>
            </Item>
        <Item>
                <Key>_CREATED_xxxmac 1</Key>
                <Value>24.09.22 11:58</Value>
                <LastModificationTime>ssvA2g4AAAA=</LastModificationTime>
            </Item>
        <Item>
                <Key>_CREATED_xxx-1</Key>
                <Value>2023-11-28 1:37 PM</Value>
                <LastModificationTime>9dX33A4AAAA=</LastModificationTime>
            </Item>