Bah. My bad again -- the breakpoint was set on if(!dir.isDir()) { and
not on the next line. So it was tripping when the dirs needed to be
created, whether or not it was successful. Bah bah bah! I need to sleep
before I do much more work on this thing...

The alternative would to insist on atomic. If it dies part way
thorough it has to delete what it created. Then what if that fails?
having a few extra dirs is not going to hurt anything. I think that
choice was reasonable given the OS does not support atomic directory
node chain creation or deletion for that matter.

that sounds like windows bug. I will speculate an WHY this happens.

Windows maintains a very expensive statistic, the time last accessed.
In theory the disks could spend their entire times updating the last
access date in the directories every time a byte is read anywhere in
the file tree, or at least is closed.  Perhaps it is defined only
measure  the last closed file -- in other words when the directory
itself was last modified.  

In any case procrastination is definitely called for.

I suspect though they over did it. They also procrastinated posting
even the existence of the directory.  Recall that Windows NT+ use a
transaction based system. Transactions to change the directory queue
up with CODASYL-like processing to make it recover in the even of a
crash during a multi sector write.

The directory existence transaction had not yet been processed.  Even
the in RAM cache apparently does not recognize the change until
officially posted.

see http://mindprod.com/jgloss/file.html#MKDIRS