Broken behavior of java.io.File()

[Twisted]

I'm seeing several examples of broken behavior with java.io.File():

* mkdirs() sometimes returns false, despite succeeding (the directories
exist afterward on the
filesystem)
* exists() and isDirectory() sometimes return false when called on a
File object right after a
mkdirs() after which the directory and its parents existed, as
observed using Winblows
Exploder.

What is going on here? Is there even a way to test for the existence of
a directory with 100% accuracy?

 

[Twisted]

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...

 

[Roedy Green]

* mkdirs() sometimes returns false, despite succeeding (the directories
exist afterward on the
filesystem)

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.

 

[Roedy Green]

What is going on here? Is there even a way to test for the existence of
a directory with 100% accuracy?

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.

 

[Roedy Green]

What is going on here? Is there even a way to test for the existence of
a directory with 100% accuracy?

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