Rescuing your Chrome history: Difference between revisions

(2 intermediate revisions by the same user not shown)

Line 3:

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.

Line 15:

# run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>

# run <tt>mv /tmp/chrome-history History</tt>

# run <tt>rm /tmp/chrome-history.sql</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.

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'''

[[Category:Blog]]

@@ Line 3: / Line 3: @@
 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.
@@ Line 15: / Line 15: @@
 # run <tt>sqlite3 /tmp/chrome-history < /tmp/chrome-history.sql</tt>
 # run <tt>mv /tmp/chrome-history History</tt>
+# run <tt>rm /tmp/chrome-history.sql</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.
+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'''
 [[Category:Blog]]

Rescuing your Chrome history: Difference between revisions

Dank (talk | contribs)