Wednesday, March 18, 2026

KMyMoney password doesn't work; can't open database

Did you recently upgrade your operating system?

Do you have KMyMoney 5.0 or above?

Did you try to open your kmymoney sqlite database and your password will not work (and you have no recollection of changing it, but maybe you did?!??)

Good news, you're not crazy. You're in the open source wild west.

KMyMoney uses sqlcipher for its encrypted sqlite databases. At some point it upgraded from sqlcipher 3 to sqlcipher 4, and the new version cannot open the old databases! They don't even tell you this, and neither does KMyMoney.

Luckily the fix is not hard.

1) Install the sqlcipher tool on your computer (eg, sudo apt install sqlcipher)

2) Open your database: sqlcipher path/to/mydb.sqlite

3) Run these commands:

After that, you should get a single row containing '0', indicating success (another number indicates failure). 

PRAGMA key = 'your_passphrase_here';

PRAGMA cipher_migrate;

you can .quit and uninstall sqlcipher if you choose.

Done. You should now be able to open your database with the latest KMyMoney. phew

Reference:  It's all made very clear in the second paragraph of the subsection on "File (SQLite/SQLCipher only)" in chapter 22 of the online manual

Monday, February 16, 2026

joe's own editor with ghostty



 There appears to be some incompatibility between the classic joe text editor and newer terminals such as Warp and ghostty which causes multi-line text which is pasted to the editor to lose the new-lines. In other words, all the lines in the pasted text appear on the same line.

This appears to be related to what is called "bracketed paste". This is a feature that allows multiple lines to be pasted at once, without the editor performing additional formatting that would happen if they were user-entered. In fact, joe seems to be the first piece of software to support this new feature of xterms back in the day.

Nowadays, most shell software supports bracketed paste, and that includes nano, pico, vi, and bash itself, as well as joe. But for some reason when joe's -brpaste config option is set to enable the feature (as is usually the default nowadays), the newlines are lost under ghostty.

The best workaround seems to be to disable bracketed paste support from joe, via the command line option --brpaste (note the second dash), or via the same in /etc/joe/joerc. This will cause pastes to appear correctly, but may cause ghostty to give a warning that such a paste may be dangerous. This warning can be disbled with ghostty's clipboard-paste-protection = false configuration option. If you're using bash or zsh, they also support bracketed paste, and as such should not execute the pasted commands until after you hit enter.

It's unclear why this happens in joe + ghostty. Bracketed paste to joe works in gnome-terminal. And bracketed paste from ghostty works in other software. Something similar was happening in nano/pico under macOS, and that was fixed. It appears that when gnome-terminal's vte uses bracketed paste, it sanitizes control characters before sending (pastify.cc:57-118). It also appears that joe has special handling for linefeeds (character 10) in bracketed pastes (main.c:152-153). So there may be unusual interactions showing up.

Monday, February 28, 2022

boost::asio tcp socket read with timeout

 You want to do a simple socket read in C++, using boost::asio. You're already in a thread dedicated to handling this connection, so it can be synchronous. Great.

size_t receivedLength = boost::asio::read(*socket, boost::asio::buffer(receiveBuffer), sizeof(receiveBuffer));

But then you realize you'll need a timeout in case something goes wrong on the other end, or it's taking too long or outside forces want you to abort. Should be simple, just add a timeout parameter, right? Wrong. Doesn't exist.

OK, well, you probably know that posix socket interface has optional timeouts. Just set the socket option SO_RCVTIMEO  and you should be good, right? WRONG! At least in Linux (and possibly elsewhere), boost::asio tcp read operations will not return at the timeout. They keep trying to read (see the aside here). It's a moot point, since it won't work anyway, but it's also finicky since the call to setsockopt is platform dependent. For posterity, this does the job:

// Set socket send & receive timeouts, after reading rcv default timeout
#define  RW_TIMEOUT_SECS 5

char timeoutBuf[16];
uint32_t sockoptlen = 16;
::getsockopt(socket->native(), SOL_SOCKET, SO_RCVTIMEO, &timeoutBuf, &sockoptlen);
if (sockoptlen == sizeof(struct timeval)) {
    std::cout << "Default receive timeout (s): " << ((struct timeval *) timeoutBuf)->tv_sec << " (us): " << ((struct timeval *) timeoutBuf)->tv_usec << std::endl;
} else { // sockoptlen == 4
    std::cout << "Default receive timeout (ms): " << *((uint32_t *)timeoutBuf) << std::endl;
}

#ifdef WIN32
const uint32_t timeout = RW_TIMEOUT_SECS * 1000;
#else
const struct timeval timeout = {RW_TIMEOUT_SECS, 0};
#endif
::setsockopt(socket->native(), SOL_SOCKET, SO_RCVTIMEO, (const char *)&timeout, sizeof(timeout));
::setsockopt(socket->native(), SOL_SOCKET, SO_SNDTIMEO, (const char *)&timeout, sizeof(timeout));

(There are asio methods to do this, but they are platform dependent and in linux/mac you have to implement a big class to use them.)


One option for having a timeout option would be to make the socket non-blocking, so async reads return immediately. Then, you poll to enforce the timeout yourself. So, you could do:

#include <chrono>
#define RD_TIMEOUT_SECS 5

socket->non_blocking(true);
size_t receivedLength = 0;
std::array<char, 1024> receiveBuffer;
auto error = boost::asio::error::would_block; clock_t start = clock(); while ( error == boost::asio::error::would_block
        && clock() < start + CLOCKS_PER_SEC * RD_TIMEOUT_SECS ) {
    receivedLength = socket->receive_from(boost::asio::buffer(receiveBuffer), 
                                         sender_endpoint, 0, error);
}
if (receivedLength > 0) { std::cout.write(recv_buf.data(), receivedLen); }

This is pretty clear and compact, but it kind of defeats the whole idea of asio, and wastes CPU time. Plus now you have to do more work to retrieve the number of bytes you expect/need. And finally, you probably also need to make sure that the connect function has a timeout, and this won't help you here. There are three other, better options, all of which work, each with slightly different drawbacks. 


The first option is the traditional, preferred asio method. It uses a deadline/steady timer and works with at least boost 1.44+. An example is here. In essence, you need to use an asynchronous read, create a timer with a timeout callback that would cancel the read if called, run the io_service (io_context in later versions) in a loop, and then check if there was an error (in the case of a timeout).

const int RD_TIMEOUT_SECS = 5
char receiveBuffer[1024];
size_t receivedLength = 0; boost::system::error_code error = boost::asio::error::would_block; boost::asio::async_read(*socket, boost::asio::buffer(receiveBuffer, sizeof(receiveBuffer), [&](const boost::system::error_code& result_error, std::size_t result_n) { error = result_error; receivedLength = result_n; }); try { // Set a deadline for the read operation. deadline_->expires_from_now(boost::posix_time::seconds(RD_TIMEOUT_SECS)); // Start the deadline actor to abort if still not connected deadline_->async_wait(boost::bind(&MyClass::checkConnectTimeout, this, _1, socket)); // Block until the asynchronous operation has completed. do { ioService_->run_one(); } while (error == boost::asio::error::would_block); } catch(std::runtime_error &e) { error = boost::asio::error::fault; } if (error) { std::cout << "Timeout reading socket." << std::endl; }

You'll also need to define your callback function to cancel the app. Both callback and boost::asio::deadline_timer deadline_ are class members.

void MyClass::checkConnectTimeout(const boost::system::error_code& ec, boost::asio::ip::tcp::socket *socket) {
    if (ec == boost::asio::error::operation_aborted) {
        // Timer was aborted.
        return;
    }

    // Check whether the deadline has passed. We compare the deadline against
    // the current time since a new asynchronous operation may have moved the
    // deadline before this actor had a chance to run.
    if (deadline_->expires_at() <= boost::asio::deadline_timer::traits_type::now()) {
        // The deadline has passed. The socket is closed so that any outstanding
        // asynchronous operations are cancelled and return an error code
        socket->cancel();
    }
}

A more compact application of this same approach can be seen here (to my knowledge it was first elaborated by Christopher Kolhoff on the boost mailing lists).


A simpler approach is possible from boost 1.68+, since you can run the io_context for a fixed amount of time using run_for(). This is shown in an example here. Basically, you need to create a new function to run the io_context and cancel the async read operation if it's not yet done when the time is up.

  void run(boost::asio::chrono::steady_clock::duration timeout)
  {
    // Restart the io_context, as it may have been left in the "stopped" state
    // by a previous operation.
    io_context_.restart();

    // Block until the asynchronous operation has completed, or timed out. 
    io_context_.run_for(timeout);

    // If the asynchronous operation completed successfully then the io_context
    // would have been stopped due to running out of work. If it was not
    // stopped, then the io_context::run_for call must have timed out.
    if (!io_context_.stopped())
    {
      // Close the socket to cancel the outstanding asynchronous operation.
      socket_.close();

      // Run the io_context again until the close operation completes.
      io_context_.run();
    }
  }

Then, you simply call it after the async read above, and before checking for an error.

const int RD_TIMEOUT_SECS = 5;
size_t receivedLength = 0;
boost::system::error_code error;
boost::asio::async_read(*s, boost::asio::buffer(receiveBuffer, sizeof(receiveBuffer)),
                        [&](const boost::system::error_code& result_error,
                            std::size_t result_n)
                        {
                            error = result_error;
                            receivedLength = result_n;
                        });

run(boost::asio::chrono::seconds(RD_TIMEOUT_SECS));

if (error) {
    LOG(lg::warning) << "Timeout reading socket" << std::endl; 
}

Similar techniques can be used for writing or connecting to the socket.


Finally, it is possible to use C++11's futures, as documented here

const int RD_TIMEOUT_SECS = 5;
std::future<size_t> futureReceivedLength =
  boost::asio::async_read(*socket,       
        boost::asio::buffer(receiveBuffer, sizeof(receiveBuffer)), 
        boost::asio::use_future);

if (futureReceivedLength.wait_for(std::chrono::seconds(RD_TIMEOUT_SECS)) 
    != std::future_status::ready) {
    std::cout << "Timeout reading socket." << std::endl;
    socket->cancel(); // cancel the operation.
    return; // do something appropriate; don't continue.
}

// this won't block because we know the future is ready. 
size_t receivedLength = futureReceivedLength.get();
// We can check the size and process the buffer

This is clean and standard, and you don't need any auxiliary functions. But you need to have the io_context run()ing in its own thread, which is probably wasteful depending upon your archittecture.

Hope this helps clear things up and save you some of the time I wasted figuring this all out.

Sunday, December 3, 2017

Installing and using opkg on recent DD-WRT routers

Sometimes you need to extend your dd-wrt router's functionality. As of current Kong builds  (at least 29000 to 34000), this is easy to do using optware and the opkg tool to install packages originally created for Open-Wrt.

But finding instructions to do so is hard. The best that can usually be found are something like this guide, which is largely out of date, and makes it sound much harder than it is. Or this which is likely also out of date and if it were to work would install a bunch of stuff you may not want or need.

All that is necessary in most cases** is:
  1. Enable JFFS under Administration->Management of the web control panel. After rebooting a nonvolatile /jffs partition will be created from flash memory.
  2. Telnet or ssh into your router (log in as root, with your admin user's password)
  3. Now, from the command prompt: make a directory to be used as /opt (where newly installed packages will be stored): mkdir /jffs/opt; mount --bind /jffs/opt
  4. Run bootstrap and say yes to install opkg. This is the well concealed secret. Bootstrap is included on Kong builds in order to install opkg for those who want it.
  5. Run opkg update to update the repository of available packages
  6. To be able to use opkg and installed packages after reboot, you need to add the line mount --bind /jffs/opt /opt to the startup script (under Administration->Management in the web control panel).
Now you have opkg installed and updated and can install packages. You can see the list of available packages by running opkg list and install them by running opkg install pkgname.

Happy opkging! Now you can do fancy stuff like install SSL certificates for your lighttpd web server.

---

Alternatively, rather than using the standard opkg, there's a new project called entware-ng which has more, and more updated applications to run on embedded devices.

To install this (which is in place of the normal opkg), skip step 4. Then follow the instructions here to install on DD-WRT (you could also install /opt on a USB device as explained there, but this is not necessary unless you want many apps or your router has little flash memory). I had luck finding some packages here that weren't available or working in the opkg repository.


* - Kong builds are for routers with ARM/Broadcom chipsets. I don't know about other chipsets or builds, but I wouldn't be surprised if brainslayer or others are building boostrap into their builds as well, so this approach may work for them too.
** - If your router does not have much or any available flash memory to create a jffs partition with, or you want to install many or very large packages, you will need to create a partition for use via USB, and mount it as /opt. Kong's own howto covers this (as well as some more tips on using opkg). The key is that you need a nonvolatile, writable subdirectory /opt, big enough to store what you want to install.

Sunday, April 23, 2017

Cadbury creme eggs ingredients


Cadbury's UK (as bought in Ireland):
Milk chocolate: Milk solids 14% minimum. Contains vegetable fats in addition to cocoa butter. Milk chocolate egg with a soft fondant centre (47%). Ingredients: Sugar, milk, glucose syrup, cocoa butter, invert sugar syrup, dried whey (from milk), cocoa mass, vegetable fats (palm, shea), emulsifier (E442), dried egg white, flavourings, colour (paprika extract).


Cadbury's US ingredients (as produced by Hershey's under license from Cadbury):
Milk Chocolate: (sugar, milk, chocolate, cocoa butter, milk fat, nonfat milk, soy lecethin, natural and artificial flavors), sugar, corn syrup, high fructose corn syrup, contains 2% or less of: artificial color (Yellow #6), artificial flavor, calcium chloride, egg whites.

These ingredients are from Easter 2017, so after Cadbury changed from using dairy milk chocolate in the UK.

Tasting them side by side, I was a bit surprised to find a significant difference. The UK eggs were richer and creamier, with a better flavor. The US eggs just tasted too sugary by comparison, and the fondant was more translucent, like sugar syrup.

Friday, March 10, 2017

Preventing Windows OS from sleeping while your python code runs

Do you have a python script that you want to run through to completion, but might take several hours without user interaction?

Might you run on a laptop or other Windows computer that has power management enabled, so that it might go to sleep or hibernate when not being used?

If you do nothing, windows will likely sleep or hibernate before your script can complete.

The following simple piece of code can prevent this problem. When used, it will ask windows not to sleep while the script runs. (In some cases, such as when the battery is running out, Windows will ignore your request.)

class WindowsInhibitor:
    '''Prevent OS sleep/hibernate in windows; code from:
    https://github.com/h3llrais3r/Deluge-PreventSuspendPlus/blob/master/preventsuspendplus/core.py
    API documentation:
    https://msdn.microsoft.com/en-us/library/windows/desktop/aa373208(v=vs.85).aspx'''
    ES_CONTINUOUS = 0x80000000
    ES_SYSTEM_REQUIRED = 0x00000001

    def __init__(self):
        pass

    def inhibit(self):
        import ctypes
        print("Preventing Windows from going to sleep")
        ctypes.windll.kernel32.SetThreadExecutionState(
            WindowsInhibitor.ES_CONTINUOUS | \
            WindowsInhibitor.ES_SYSTEM_REQUIRED)

    def uninhibit(self):
        import ctypes
        print("Allowing Windows to go to sleep")
        ctypes.windll.kernel32.SetThreadExecutionState(
            WindowsInhibitor.ES_CONTINUOUS)


To run it, simply:

import os

osSleep = None
# in Windows, prevent the OS from sleeping while we run
if os.name == 'nt':
    osSleep = WindowsInhibitor()
    osSleep.inhibit()

# do slow stuff

if osSleep:
    osSleep.uninhibit()

It is based on code from here, which also has code for preventing suspension on Linux under GNOME and KDE, should you need that.

Thursday, March 2, 2017

ufsd NTFS driver on mount: Fixing 'Unknown Error 1000'

I've previously mentioned using the ufsd driver for NTFS or HFS+, because it is significantly faster at writing than the default ntfs-3g driver provided with in Linux, and it supports writing for HFS+ drives even with journaling enabled. (It is available free for non-commercial use).

But what happens if you have a hard power down with an NTFS drive mounted? Or you encounter corruption for whatever reason?

UFSD may give this error upon mounting it for read-write:

mount: Unknown error 1000

This error is because the "dirty" flag is set on the drive and ufsd won't mount it read/write for fear of corrupting it. In many simple cases, you can correct errors in Linux with ntfsfix, from the ntfsprogs package, and also use ntfsfix to clear the dirty flag.

So if the volume in question is /dev/sdb1, I could do the following as root while the drive is unmounted. The first command repairs simple issues. The second clears the dirty flag:

root ~ # ntfsfix /dev/sdb1   
root ~ # ntfsfix -d /dev/sdb1

IMPORTANT NOTE: If you have extremely valuable data, especially that was being written when the failures occurred, you should be very cautious, because these commands may cause you to lose data.

A better approach may be to load Windows and run chkdsk /f  (to fix file system errors) or chkdsk /r (to detect and mark bad sectors) on the offending drive. Chkdsk is much more sophisticated at detecting and fixing errors than anything available in Linux, although it too may cause you to lose data (and some data loss may be inevitable if power goes off while writing). Here is one approach (using a bootable CD) to using chkdsk even if you don't have Windows installed or handy.

Final note, if this drive is not critical for your machine and you mount it from fstab, you can add the errors=remount-ro flag to the fstab mount line, in order to avoid hanging up your boot when things go wrong.