> Is there a command to undelete files?  Or possibly a utility?

Probably not.  It depends on the filesystem in use, and possibly other
things (for example, have you created anything on the filesystem after
doing the delete?)

> I deleted a group of files from my web sever (mac68k NetBSD 1.5), and
> it turns out, I was wrong and I didn't have a current backup of the
> files.  So now I'm trying to see if I can resurrect them before I
> have to recreate them the closest version I do have a backup of.

> Anyone have any advice?  (besides be more careful next time)

Well, yeah, there's that, but somehow I think you don't need to be told
that. :-)

First, don't write anything more to that filesystem.  Make an image of
it somewhere (I'm talking a dd-level image of the partition, not a
filesystem-level image such as rsync or cp -r produces).  Then you can
hack around with it without losing possibly-precious information.

It's too late for this this time, but if you realize your mistake
before the command completes, the best chance you have is to turn the
machine off, immediately, and as ungracefully as you can - don't give
it any more chance to flush things to disk than you can help.  (I don't
know whether mac68k has anything like the i386 ctl-alt-esc or the SPARC
L1-A to drop to ddb, but if so that would be a good thing to use - you
want to freeze on-disk state as immediately as you can; turning the
machine off is just a drastic form of that.)  Then image the partition
somewhere else.

If you're using ffs, which I imagine you probably are, the situation is
not good.  All your deleted bits are there (unless they've been
overwritten, which is why I said to not write anything to the
filesystem if you can help it), but the pointers that would let you
find them easily have been destroyed.  If you know some distinctive
byte sequence that occurs in the deleted files, searching your disk
image for that sequence can often find you relevant disk blocks.  And,
while files are not guaranteed to be contiguous, they turn out to be
often enough that it's worth looking at the adjacent blocks to see if
they're adjacent parts of the file.

If the removal didn't quite complete (and I recognize that it's too
late for that in this case), you maybe can identify the blocks by
looking for blocks which are marked as busy in the in-use bitmaps but
not claimed by any inode.

Some of these techniques require a fairly intimate knowledge of the
filesystem in question, which I assume you don't have or you wouldn't
be asking.  Depending on the level of effort you want to put into
scaring up the deleted data and how much value you put on knowing stuff
against possible future use, you may end up learning....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B