disklabel -create breaks newfs'd USB drive

Months ago, I got a new USB drive, did "newfs /dev/disk1" on it, and
it's been working fine ("mount /dev/disk1 /mnt/foo" worked fine).

While preparing to back it up for the first time, I did
"disklabel -create /dev/disk1", which broke it:

# mount /dev/disk1 /mnt/foo
/dev/disk1 on /mnt/foo: Incorrect super block.

How can I fix this?

I used "less -f" and see that disklabel has written this to my drive:

[bunch of mostly null characters, followed by:]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Base</key>
        <integer>131072</integer>
        <key>Size</key>
        <integer>500107730944</integer>
</dict>
</plist>

[followed by: bunch of mostly null characters]

so I'm not surprised the "super block" is broken. If I remember
correctly, the "super block" is binary data in block 0.

I tried "fsck -b 8193" (use alternate superblock) and several variants
to fix it. I even wrote a Perl script that tried "fsck -b x" for x
going from 1 to one million, but nothing worked.

When I use "less -f", I can see my file/directory names and even the
content of my files, so I don't think anything is actually lost.

If I can't fix, is there a way to recover content from a broken
"newfs" file system?

Apologies for the cross-post: I'm desparate to get this working
again. This happened just as I was setting up a second USB drive to
back this one up, so I don't even have a backup of the "lost" data.

-- 
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
_______________________________________________
NMLUG mailing list
[email protected]
http://lists.b9.com/cgi-bin/mailman/listinfo/nmlug