Fixing Subversion's 'database disk image is malformed' Error in Working Copies

You run svn status or svn update and get svn: E155036: sqlite[S11]: database disk image is malformed — or its cousin, sqlite[S8]: attempt to write a readonly database. The working copy is unusable, but your uncommitted changes are still sitting in the files. The good news: this error is about the local metadata database, not the repository, and in most cases you can either repair it or rebuild the working copy without losing work.

Since Subversion 1.7, each working copy keeps all its metadata in a single SQLite database at .svn/wc.db (the WC-NG format). That design is fast and robust on local disks, but it inherits SQLite's hard requirements: reliable file locking, atomic writes, and enough disk space. When any of those break, the database can end up malformed.

What usually causes it

Step 1: Confirm the corruption

Before changing anything, verify the database is actually damaged. From the working copy root (read-only, safe to run as your normal user):

sqlite3 .svn/wc.db "PRAGMA integrity_check;"

If the output is exactly ok, the database file is structurally fine and your problem is locking or permissions, not corruption. Anything else — lists of malformed pages or missing indexes — confirms real corruption. If sqlite3 is not installed, use your distribution's package manager; any recent SQLite 3 build works for this check.

Also check for unclean-shutdown artifacts:

ls -la .svn/ | grep -E 'wc.db-(wal|shm)'
df -h .   # disk space
df -i .   # inode exhaustion, common on build machines

Step 2: Preserve uncommitted work first

Before any repair attempt, copy your modified files somewhere safe. The database may be unrecoverable, and svn cleanup can discard in-progress state. A quick way to capture your changes:

cp -a /path/to/wc /path/to/wc-backup

Never delete .svn/wc.db directly — it holds merge-tracking and local-state metadata you cannot reconstruct.

Step 3: Fixes matched to findings

Unclean shutdown (leftover -wal/-shm files)

Run svn cleanup from the working copy root. On SVN 1.10 and later this resolves most journal-related corruption. On 1.7–1.9, cleanup is weaker; if it fails, delete only the wc.db-wal and wc.db-shm files (never wc.db itself), then retry svn cleanup.

Disk full

Free space (or raise the quota), then run svn cleanup. Re-run the integrity check afterward — a partial write may have left damage cleanup cannot fix.

Network filesystem

Subversion explicitly does not support working copies on NFS, SMB, or CIFS because SQLite's locking protocol cannot be guaranteed there. The durable fix is to relocate: check out a fresh working copy on local disk and migrate your changes:

diff -ru --exclude=.svn /path/to/fresh-wc /path/to/wc-backup > my-changes.patch
cd /path/to/fresh-wc
patch -p0 < my-changes.patch

Review the patch before applying; paths and context may need adjustment.

Antivirus or indexer interference

Add the working copy directory (or at least .svn) to the AV/indexer exclusion list, then run svn cleanup. If errors were intermittent and the integrity check passes, this alone usually resolves it.

Irreparable corruption

If PRAGMA integrity_check still reports errors after cleanup, abandon the working copy. Check out fresh, then reapply your saved changes from the backup using the diff/patch approach above.

Step 4: Verify the repair

1. svn status completes with no sqlite errors.
2. sqlite3 .svn/wc.db "PRAGMA integrity_check;" returns ok.
3. Make a small test edit, run svn diff, then svn commit --dry-run (or commit and revert a trivial change) to confirm the write path works.
4. If the WC was moved or restored, confirm svn info shows the expected repository URL and UUID.

When to escalate

• Integrity check still fails after cleanup and a fresh checkout is impossible (e.g., huge WC with extensive local state) — dump what you can with sqlite3 .svn/wc.db .dump and file an issue against Subversion with that output.
• Corruption recurs on a local disk with free space and no AV involvement — suspect a client bug; note your SVN version (svn --version) and upgrade to the latest 1.14.x before reporting.
• You suspect the repository itself is damaged (errors on the server side, or multiple clients failing identically) — ask the repository administrator to run svnadmin verify /path/to/repo. That is a server-side operation and outside working-copy repair.

Preventing recurrence

Keep working copies on local filesystems, exclude .svn from antivirus scanning, avoid running a GUI/IDE client and the command-line client against the same WC simultaneously, and don't kill SVN processes mid-operation. For very large working copies (100k+ files), periodic svn cleanup --vacuum (SVN 1.14+) keeps the metadata database compact. Version note: behavior described here applies to the SQLite-backed WC-NG format used by all SVN 1.7+ clients; cleanup recovery improved notably in 1.10.