Hickory Accounting

Hickory Accounting is built with one goal above all: to protect your financial data.

Its design is focused on reliability, integrity, and long-term stability  because your records deserve to last a lifetime.

Proven Stability

Hickory has been in continuous personal use by its creator for over 16 years, managing real financial data without a single corruption event. The same mechanisms that keep those records safe are built into every copy of Hickory today.

Built for Data Integrity

SQLite Engine  Hickory uses SQLite, a rock-solid database engine trusted by banks, browsers, and operating systems worldwide.

Atomic File Locking  Every database operation is protected by a carefully designed symlink-based locking system to prevent corruption, even when multiple clients or network mounts are involved.

Safe over SSHFS  Hickory's database layer is tested for safe operation on remote or network-mounted files (such as SSHFS), with lock coordination and fail-safe timeouts.  ("sshfs_sync,cache_timeout=1,writeback_cache=no")

Crash Protection  All transactions use synchronous commits to guarantee the database is always in a valid state  even after unexpected shutdowns or power failures.

Responsible Backup Design

While Hickory is designed to protect your data, no system is immune to hardware failure.

That's why Hickory includes gentle reminders to make backups, encouraging good habits without getting in your way. Your data always stays local and under your control.

Local, Private, and Yours

Your financial records never leave your computer. There are no cloud accounts, no background syncs, and no tracking  just a private, efficient, text-based accounting environment you fully own.

Using SQLite over networked filesystems like SSHFS or Tailscale can easily lead to database corruption if multiple processes try to write at the same time. Traditional SQLite locking can fail over networked mounts due to caching and latency issues.

I developed a reliable, cross-client locking system for my TUI-based personal accounting app, Hickory Accounting, which ensures safe SQLite access even over SSHFS.

Key Features:-------------------------------

Atomic Symlink Locking

Each process attempts to create a unique symlink as a lock.

The atomic symlink() system call guarantees that only one process can acquire the lock at a time.

This works safely even over SSHFS with proper mount options (sshfs_sync, writeback_cache=no, cache_timeout=1).

Graceful Signal Handling, The app traps SIGHUP, SIGTERM, and optionally SIGINT.

If the process is in the middle of critical DB work, it delays exit and sets a flag (gotHangup) for safe cleanup later.

Ordinary termination signals are caught, but SIGKILL still bypasses the handler (as expected in Linux).

Stale Lock Recovery / Timeout

If a process crashes or is killed with SIGKILL, the symlink lock persists.

The system automatically releases the lock after 10 minutes, ensuring no permanent deadlocks.

Cross-Environment Testing

Tested locally and over Tailscale + SSHFS.

Only a forced kill -9 could interrupt the process mid-write, but the timeout mechanism safely recovers without harming the SQLite database.

Simple Integration

Functions lockSqliteDb() and unLockSqliteDb() wrap the locking logic.

Supports long-term locks (lockedByThisInstanceLongTerm) for multi-step transactions, preventing race conditions.

Why This Matters:-------------------------------

Many developers assume SQLite is unsafe over networked filesystems. By using atomic symlink locks, combined with graceful signal handling and auto-expiring locks, this system provides:

Safe multi-client access over SSHFS

Protection against crashes and network issues

Minimal dependency on external services or databases

Notes:-------------------------------

This method works well for personal / family or small team projects.

For high-frequency writes or very large teams, a server-based database (PostgreSQL, MySQL) may still be preferable.