fsck and the vmware-vdiskmanager check work on different layers. vmware-vdiskmanager checks that Fusion's representation of the virtual disk is consistent; fsck checks that the guest filesystem is consistent. It's like the difference between checking a drive for S.M.A.R.T. errors and doing fsck.
The screenshots may indicate a bad block on the physical hard drive - if the error was confined to the virtual machine, it should not cause Fusion to throw an error. If you look at the end of the log, Fusion seems to be failing to read the same address and eventually gives up. Since we use standard APIs to read/write files, this is unlikely to be a problem with Fusion and rather a problem with the hardware or the host filesystem.
I thought perhaps I could use the new 2.0.1 feature and mount the drive on my Mac and delete the file from there and perhaps that would fix it. But if I try to mount the 00001.vmdk file, I get the error "Failed to mount partitions: The virtual disk does not have any partitions that the host system knows how to mount." If I try to mount the larger .vmdk file, I get the error "It is not safe to mount the virtual disk. It may be attached to a suspended or powered-on VM, or it may be inside a snapshot chain."
The larger .vmdk file is indeed inside a snapshot chain - the 00001,vmdk file is a snapshot and depends on the original. Since you're using a Linux guest, it probably has an ext2 or ext3 filesystem. Unfortunately, OS X does not understand this, so even though Fusion can go "here's a disk", OS X stares at it blankly. There's an experimental ext2 filesystem plugin which would make this work, but I hear it has stability issues.
I think your best bet is to either override the fsck check (not sure if you can do this, but I would naively suspect you can) or boot from some other media that can recognize the filesystem (either a live CD or create a new virtual machine and attach the existing vmdk - if you do the latter, make sure to use the child -00001.vmdk, not the base disk).