To expand on what zahc said, based upon my own knowledge (Most of this is fact. The details of the exact implementation within wubi are speculation, but chances are I'm correct):
Linux treats all disk drives (to include USB flash drives, CD/DVD, hard disk partitions, and so forth) as something called "block devices", meaning "devices that blocks of data can be read from (and in most cases, written to) in random order".
In order to be used as a place to store files, a block device has to have a "filesystem" created in it. That's the thing that tracks were and how big all of your files are, and so forth. Linux also has the ability to use what's called a "loopback device" to pretend that a file, which exists in another filesystem, is a block device, which can then have its own (possibly different) filesystem built inside it.
What Wubi is doing is mounting the Windows filesystem (NTFS) and creating a file in it. Then it is attaching that file to a loopback device driver, and thus creating for itself a virtual disk drive within that file. Then it's creating its own filesystem on top of that virtual disk, and installing Ubuntu on top of that filesystem.
This is an easy way to do this sort of thing, from an end-user standpoint, but it is not a robust one, technically speaking.
The reason it's not robust is because of something that both NTFS and most modern Linux filesystems (including ext3, ext4, xfs, jfs, and reiserfs) do, to prevent data loss in the event of a sudden shutdown. Data that is to be written to disk is first written in something called a "journal", and then (at periodic intervals) it's flushed from the journal to the actual filesystem. That means that at no time is there ever a completely inconsistent copy of the data on the disk. Either it's totally there (though possibly old) in the main store but partially written in the journal, or it's complete in the journal, but not yet fully written to the main store, or it's successfully written to the main store and flushed from the journal.
The problem comes when you layer a journaling filesystem inside a loopback-based file on top of another journaling filesystem; the interior filesystem thinks he's running on a bare disk, but his written blocks may be cached, journaled, and written out of order by the exterior filesystem, because the journal guarantees integrity, not sequentiality.
So if the internal filesystem (for instance) writes part of a file change from its journal to a file, and flushes that part of its journal, but only the block containing the flushed journal is written to the physical device by the exterior filesystem before power is shut off, you're left with an inconsistent state in the interior filesystem.
This is why you should never ever just shut off any machine that's got a virtual loopback filesystem running on it.
-BP
