Recovery's Sordid Tale

Operating systems before UNIX used file systems with the concepts of versions for files and recovery
for files deleted accidentally.  UNIX features neither idea.  OpenVMS, a later operating system, has
the former concept in a shape which provides much of the latter.  I only know vaguely how the system
behaved, but know it exposed a useful interface: Files got versions unless directed otherwise.  UNIX
uses one interface for all file operations: Deletion is meant to be permanent, without a distinction
between temporary files or users' files.  Any system must be able to express an idea or its shape in
some way if it will be supported, and UNIX fails this, because each program would need to be updated
for features like versions or undeletion of files to exist within its boundaries.  UNIX lacking such
flaws ceases to be UNIX, and becomes something better, since UNIX is defined entirely by what simple
tasks it makes either hard or impossible.  I use not git, and have read of much work lost therefrom.

I've recovered a file from GNU Emacs under OpenBSD, years ago.  I opened Emacs' core dump in itself,
from there searched the contents for a string I knew to occur in the buffer, and found it easily.  I
know programs shouldn't need to use such base representations in pursuit of efficiency, IBM machines
have the concept of channels which perform work from decompression and decryption to parsing XML all
without bothering the primary processors, but under UNIX those programs which can have a file dumped
directly into their address spaces as the preferred representation perform best and delude many into
believing this to be some simple truth.  Regardless, Emacs' use of such made it easy to fish it out.

Earlier in this month, I did something of which I've read no prior accounts.  I accidentally damaged
one of my redundant long-term storage drives, and I'm waiting to see if the data can be recovered in
any meaningful way.  I'd kept a special configuration of GNU Emacs on my Lemote YeeLoong and on this
drive, as an ersatz security key in the latter case.  This configuration was for the Gnus subsystem,
and took me around eight hours to write at the time.  I've been preparing to wipe my Lemote YeeLoong
and update its outdated OpenBSD installation; I recently tidied the file system to make this easier,
and the configuration hadn't made the cut to remain.  I was carrying on not unawares of my lack of a
backup, and I had all vital information written on a sheet of paper, but after damaging this drive I
certainly wanted not to use it prematurely and damage it further but for access to this single file.

UNIX pretends to be a file-based operating system, and OpenBSD follows that trend.  Accordingly, the
file representing my Lemote YeeLoong's ``raw'' storage device, a solid state drive of ten gigabytes,
was also a file, one named /dev/wd0c.  I knew a string occurring in the file I wanted to recover and
I'd deleted files only as of my last use, so I knew I may use grep to search the file system storage
directly to find it.  My first instinct was to use Emacs, but I instead foolishly attempted to use a
``traditional'' tool for this, less.  OpenBSD's iteration of less demanded I pass the flag f, force,
to open a ``special'' file; I gave it the search string and, as the system is rather slow, I waited.
I after fifty minutes saw the light indicating access to the storage wasn't flashing, so I correctly
figured the program to have crashed.  I was unable to regain control of the system, so shut it down.
I found it fitting to have yet another example of some UNIX software's failure resolved by hardware.

For my second attempt, I started an X11 session with Emacs; at first, I nearly ran fgrep in an xterm
window, before realizing that to be stupid and using eshell, although I made certain to run the true
fgrep and not an Emacs Lisp function.  I was unable to open the device's file in Emacs directly, but
had no need: The contents of my file, alongside a mass of virtual sewage, was found easily enough by
fgrep.  I'd seen less to have dumped core, but it fortunately had overwritten nothing important with
its worthless information.  I made fgrep list file offsets with its output, but I found no option to
have it use these to optimize future searches, so I repeatedly called fgrep with larger contexts and
later strings to recover as much of the file as I needed.  I may have been able to call upon another
command, such as head or sed, to make use of the offset, but I was thoroughly through thinking about
this matter.  UNIX is the only operating system in which I've had to dig through its guts like this.

I afterwards had a nice glass of whiskey and reflected on how worthless is the knowledge to do this.
.