GNOME Bugzilla – Bug 610707
Attempting 'save as' to xml file results in sqlite3 file instead
Last modified: 2018-06-29 22:35:28 UTC
With the current svn trunk, I read a copy of my most recent gnucash xml datafile, made a change to one transaction and then tried to do a 'save as' to a different xml file. The xml/sqlite3 pulldown at the top of the file dialog showed 'xml', which it does by default (I also tried actually setting it to sqlite3 and then back to xml, rather than just relying on the default; this had no effect on the outcome). However, the resulting file was a sqlite3 file, which I know because I wanted to look at it, tried to gunzip it, which told me it wasn't a gzip file. I then ran the 'file' command on it, and it reported that it was a sqlite3 file: $ file Test2 Test2: SQLite 3.x database
Confirmed - caused by recent checkin 18699. Function xaccResolveURL() converts string "xml:///home/phil/file" to "/home/phil/file" which assumes "file" URI type, which can be handled by both sqlite3 and xml (needed to read a file from of either type just by specifying file name).
Interesting. I'll investigate how that went wrong. In the meantime, I've reverted 18699.
Thanks. The only clue I can provide is that your change to xaccResolveURL() removes the code that adds "xml:" back on after xaccResolveFilePath() removes it. You may need to keep something like that since there are a few URI types (file:, xml: and sqlite:) which all take a file path.
I've looked over the code again, and now I see that if xaccResolveURL is passed a URI (meaning a string that starts with http:, https:, file:, xml:, or a "registered" scheme), it returns exactly what it was fed, except: * file: URIs get normalized to a full path. That path isn't checked to see if it exists. * xml: URIs get normalized to remove a "//" part; again, the path isn't checked. Similarly, a full path name (meaning some string that starts with the file separator or, on M$Win, a drive letter) is returned without checking. Only a relative path name (meaning a string that doesn't match the URL detection above and doesn't start with a file separator or drive name) gets checked; if it doesn't exist, a path to it in the GNC_DOT_DIR is returned. Consider that a bad scheme name will be treated as a relative pathname. That could prove interesting. The only thing getting resolved are relative paths, not URLs. Shouldn't the full paths at least be checked to make sure that the directory exists and that the user can write to it? (Gee, it could call gnc_validate_directory()!) Shouldn't invalid schemes produce an error?
OK, the whole thing is just ugly. I've commented it for doxygen, explaining in detail what's going on; I can only hope that someone with a bit more experience of how the backends work can rework xaccResolveURI(), xaccResolveFilePath(), and all of their callers so that these functions do something useful -- or are removed. I've also added some tests to catch this in future. Committed as r18765.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=610707. Please update any external references or bookmarks.