Rescuing your Chrome history - revision history

Dank at 03:02, 26 May 2026

2026-05-26T03:02:53Z

← Older revision		Revision as of 03:02, 26 May 2026
Line 15:		Line 15:
	# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>		# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>
	# run <tt>mv /tmp/chrome-history History</tt>		# run <tt>mv /tmp/chrome-history History</tt>
			# run <tt>rm /tmp/chrome-history.sql</tt>
	# start Chrome		# start Chrome

	you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with <tt>mktemp</tt> invocations.		you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with <tt>mktemp</tt> invocations. you ought write them to a directory that is not world-readable, unless you don't mind people being able to read your browser history.

	'''previously: "[[GT2025\|GT2025]]" 2025-04-17'''		'''previously: "[[GT2025\|GT2025]]" 2025-04-17'''

	[[Category:Blog]]		[[Category:Blog]]

Dank at 02:15, 26 May 2026

2026-05-26T02:15:36Z

← Older revision		Revision as of 02:15, 26 May 2026
Line 3:		Line 3:
	has it really been over a year since i blogged here? sheesh.		has it really been over a year since i blogged here? sheesh.

	for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memory and on disk</i>, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.		for going on a decade at least, Chrome (at least the [[Debian\|debianized]] "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memory and on disk</i>, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.

	if you close chrome and start it again following this corruption, the database (<tt>History</tt> in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.		if you close chrome and start it again following this corruption, the database (<tt>History</tt> in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.

Dank: Dank moved page Rescuring your Chrome history to Rescuing your Chrome history: Misspelled title

2026-05-26T02:14:02Z

Dank moved page Rescuring your Chrome history to Rescuing your Chrome history: Misspelled title

← Older revision	Revision as of 02:14, 26 May 2026
(No difference)

Dank: Created page with "'''dankblog! 2026-05-25, 2201 EDT, at the danktower''' has it really been over a year since i blogged here? sheesh. for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant `User Data/` subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database in memor..."

2026-05-26T02:13:43Z

Created page with "'''dankblog! 2026-05-25, 2201 EDT, at the danktower''' has it really been over a year since i blogged here? sheesh. for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memor..."

New page
'''[[Dankblog|dankblog!]] 2026-05-25, 2201 EDT, at [[Viewpoint|the danktower]]'''

has it really been over a year since i blogged here? sheesh.

for going on a decade at least, Chrome (at least the debianized "Chromium" builds i run) has serious problems if your filesystem fills up (the filesystem holding the relevant <tt>User Data/</tt> subdirectory, to be precise). foremost among these issues is that the next pageload results in a corrupted history database <i>in memory and on disk</i>, meaning your history becomes null ("what?" you ask. "how can it corrupt the database on disk if the disk is full?" that's a great question, one to which i'd like to know the answer. obviously it's editing something in-place, or reserved some space, but it definitely happens.) visited sites can't be seen, and new loads aren't recorded. this seems a pretty substantial bug, but i guess no PM in mountain view gives a shit. so it goes. i have no insight into the mysteries of Chrome development planning.

if you close chrome and start it again following this corruption, the database (<tt>History</tt> in the user folder) is helpfully recreated from scratch, aka permanently lost. this is not usually what you want.

if you notice the problem has occurred (you'll typically get a "you need to free up space!" message in Chrome), take the following steps:

# change to the relevant subdirectory of <tt>User Data/</tt>, usually <tt>Default</tt>
# run <tt>sqlite3 History .recover > /tmp/chrome-history.sql</tt>
# close running Chrome processes
# clean up necessary space, you disgusting hoarder
# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>
# run <tt>mv /tmp/chrome-history History</tt>
# start Chrome

you ought have the vast majority of your history. obviously you can and should replace the hardcoded filenames with <tt>mktemp</tt> invocations.

'''previously: "[[GT2025|GT2025]]" 2025-04-17'''

[[Category:Blog]]