filed under: family, geek, netbsd, programming

Posted 496 days ago

Waaaay back in April of 2006, my cousin Karen (and her husband David) had a hard drive failure, resulting in the loss of all their digital pictures of their baby daughter Ella. They didn’t have backups, and they didn’t have prints. Computer shops weren’t able to help, and clean-room data recovery was too expensive. Eventually, they gave up on it and sent an email to the family asking if we could send them copies of any pictures we had.

I, being a geek, offered to take a look at the drive and see if I could get anything off of it. They, lacking any better options, sent the drive to me so I could give it a shot.

I dropped the drive into my NetBSD machine and sure enough, the BIOS recognized it. That meant that the drive was still physically working, and that I might have a chance at getting whatever data was left off the drive. I was able to mount the drive (read-only) and read data from it, which meant that there was a good chance of finding at least some of the pictures.

I did a bunch of googling and learned a lot about home-brew data recovery. To sum it up, I learned that you need:

1. A copy of the dd utility that supports the conv=noerror argument. (netbsd’s dd does)
2. A handy program that knows how to find images on a raw drive image. (See below)

I was able to make a copy of the bad drive (onto a good drive of mine) using dd and the instructions on this page. There were a lot of bad drive sectors encountered during the copy, which was to be expected given the fact that the drive had failed in the first place, but I was hopeful about finding at least some of the images. And having the drive copy was a big win – it meant that I could work with a copy that wouldn’t get worse if the hard drive took a dive.

The hard part was finding a program that could recover the images. For a long time I thought I was going to have to write my own, and that seemed a daunting task, but I finally found this guy who had this exact same problem and already wrote this program. It was exactly what I needed – a program that would find and extract images from a raw drive!

The only problem was that jpg-recover was running at about 15kb/s. At that rate, getting through the 80gb hard drive would have taken about 60 days to finish. I didn’t have 60 days (without interruption!) to wait.

So I dug into the code and discovered that it was horribly innefficient. It was reading data one byte at a time, checking for an image after each byte read, and just generally not being smart about performance. I set about improving it.

I was able to do so. My version takes more memory (a configurable amount) but it runs much faster: at about 12000kb/s. That’s 800x faster :) At that rate, it only took about two hours to finish, finding (after some tuning) 4,422 potential images, of which 187 were uncorrupted pictures of Ella – including this one.

That felt good :)

I’ve published my version of the program as jpg-recover-faster. It’s a perl script, so you’ll need perl. I make no guarantees about the lack of bugs – use this script at your own risk. It may eat your children. ;)

You’ll want to read the comment at the top of the script before using it, and the other pages listed above will help you figure out how to use it. Feel free to post comments here with questions or suggestions.

Add a comment [7]

filed under: geek, netbsd

Posted 504 days ago

Description

This recipe tells how to configure a linux/unix/BSD machine and a Windows machine such that the unix machine can print to a printer attached to the Windows machine, even if it isn’t a postscript printer. This could also be adapted to work for OSX client machines.

How it works

Starting from the unix machine, a print job travels thusly:

1. User prints something to a CUPS-configured print queue
2. CUPS generate a postscript version of the printout, using Ghostscript and/or foomatic and/or gimp-print
3. CUPS passes the postscript file to Samba which passes it over the network to a network-shared (virtual) postscript printer on the Windows box
4. The virtual printer takes the poscript file and gives it RedMon which gives it to Ghostscript (on the Windows box), which prints it out to the actual printer

There’s a bit of work on the Windows side to set up Ghostscript and the virtual printer, and another bit of work on the unix side to set up Samba so you can print over the network, and then another bit of work to set up CUPS so it can accept printjobs and route them to Samba.

Read more...

filed under: geek, netbsd

Posted 806 days ago

...from my new NetBSD machine, running Firefox on X, that is :)

Just a quick note to the geeks out there that I’ve gotten X working on my NetBSD machine, along with:

• Xfce as the window manager, although I tried KDE and Gnome also
• XDM as the machine logon screen
• Firefox as the browser
• Java 1.5 working as a Firefox plugin (which required Linux emulation, via Suse)
• Thunderbird as the email client
• OpenOffice as the office suite
• The BitStream fonts so web pages don’t look ugly

So that’s pretty cool – I was just able to log in graphically, check my email using Thunderbird, open a Word doc attachment and make changes. Then, just for kicks, I played some online java games, to prove that I could :)

But here’s the best part: I did (nearly) all of it using pkgsrc, just by typing “make install” in the right places. (And yes, the linux emulation just happened automagically.) Damn, but I love NetBSD.

Add a comment [5]