Summary: | .kmy file contains invalid characters | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | Alan Prescott <alanjprescott> |
Component: | file | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED WORKSFORME | ||
Severity: | minor | CC: | ralf.habacker |
Priority: | NOR | Flags: | ralf.habacker:
Backport-
|
Version: | 5.0.7 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
QXMLEdit Error
attachment-4036352-0.html |
Description
Alan Prescott
2019-12-27 16:28:25 UTC
Created attachment 124741 [details]
QXMLEdit Error
Sorry, forgot to attach the screenshot - here it is
I just found this bug report, no idea how it completely slipped through the cracks. Did you ever resolve the problem? Did KMyMoney successfully read the file? Does a newer version (either 5.1.3 or a version built from master branch) work? By "character 0" do you mean the digit 0, or a null character of value 0? Null's generally do not belong in regular character strings, but I can't imagine how KMyMoney would have put it there, unless it was part of an imported transaction. I'll save any further question in case you no longer have the file, no longer use KMyMoney (I hope not,) or otherwise choose not to respond. Created attachment 176254 [details] attachment-4036352-0.html We're going back a fair way but ... It was a character value 0 `chr(0)` and KMyMoney worked successfully with the file. Looking though my KMyMoney folder I found a saved file from that time and I've tried to open it with qxmledit and get the same bad character error message. I've tried the same with a more recent .kmy file (yes, I'm still using it, happily, thanks) with no problems so it was probably a one-off. I think I reported this mainly because I couldn't think of a way of accidentally embedding a non-printable ASCII character in an XML file - OK so Ctrl-V followed by a control char keystroke (like Ctrl-G etc) during text input works in a tty, but I don't think even that works for `chr(0)` :-) If nobody else has reported this as a problem I'd guess you can ignore it. Thanks for getting back to me :-) Alan Prescott alanjprescott@gmail.com On Sun, 1 Dec 2024 at 03:33, Jack <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=415614 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #2 from Jack <ostroffjh@users.sourceforge.net> --- > I just found this bug report, no idea how it completely slipped through the > cracks. Did you ever resolve the problem? Did KMyMoney successfully read > the > file? Does a newer version (either 5.1.3 or a version built from master > branch) work? By "character 0" do you mean the digit 0, or a null > character of > value 0? Null's generally do not belong in regular character strings, but > I > can't imagine how KMyMoney would have put it there, unless it was part of > an > imported transaction. I'll save any further question in case you no longer > have the file, no longer use KMyMoney (I hope not,) or otherwise choose > not to > respond. > > -- > You are receiving this mail because: > You reported the bug. I'm closing as WORKSFORME, since it would have been a bug if KMM itself put that null char in the data, even if during an import, and you got the error with other apps, not KMM itself. As to how that character got there, you are correct - it shouldn't have happened, but we certainly won't figure it out now. I'm guessing an import, but I'm not sure, and the import code has probably changed enough. |