Cannot destroy ZFS snapshot: dataset already exists

I have a server (T5220, though I doubt it matters) running Solaris 10 8/07 and I have a ZFS pool, "mysql", on internal disk. Within it I have a filesystem "mysql/data/4.1.12", which I snapshot hourly with a script from cron.

I have one snapshot, created as one of those hourly snaps, that will not destroy. I have renamed it out of sequence to be "mysql/data/4.1.12@wibble" so that my script will not try and fail to destroy it, but it was originally within the sequence, though I doubt that matters. It renames successfully. The snapshot can be successfully navigated and read from through the .zfs/snapshots directory. It has no clones based on it.

Trying to destroy it does this:

(265) root@web-mysql4:/# zfs destroy mysql/data/4.1.12@wibble
cannot destroy 'mysql/data/4.1.12@wibble': dataset already exists
(266) root@web-mysql4:/# 

which is apparently nonsensical: of course it already exists, that's the point!

Anyone seen anything like this before? Web searches show nothing obviously similar.

I can provide patches installed if necessary.

This issue has now been answered, courtesy of Cindy Swearingen (cindys) here: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0

Summary: If you do incremental receives, this might be CR 6860996:

A temporary clone is created for an incremental receive and in some cases, is not removed automatically.

1. Determine clone names:

# zdb -d <poolname> | grep %

2. Destroy identified clones:

# zfs destroy <clone-with-%-in-the-name>

It will complain that 'dataset does not exist', but you can check
again(see 1)

3. Destroy snapshot(s) that could not be destroyed previously

After having upgraded to more recent patch sets, I could delete this snapshot successfully. Clearly was a bug somewhere that Sun squashed.

Whilst this solution is probably unrelated to the OP's issue, I also had this same cryptic error message when trying to delete a zvol.

In my case, the zvol had been created by an interrupted zfs receive, which was sent using the "-s" resumable feature. The resume token was preventing it from being destroyed.

To fix it, I ran zfs receive -A <pool/zvol> (on FreeBSD 10.3)