Broken behavior of java.io.File()  
Index ‹ java-programmer
Author Message
Twisted
PostPosted: 2006-2-23 10:14:00 Top
java-programmer, Broken behavior of java.io.File() 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
PostPosted: 2006-2-23 10:18:00 Top
java-programmer >> Broken behavior of java.io.File() 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
PostPosted: 2006-2-24 1:42:00 Top
java-programmer >> Broken behavior of java.io.File() On 22 Feb 2006 18:14:29 -0800, "Twisted" <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>* 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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
 
Roedy Green
PostPosted: 2006-2-24 1:49:00 Top
java-programmer >> Broken behavior of java.io.File() On 22 Feb 2006 18:14:29 -0800, "Twisted" <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
 
Roedy Green
PostPosted: 2006-2-24 1:57:00 Top
java-programmer >> Broken behavior of java.io.File() On 22 Feb 2006 18:14:29 -0800, "Twisted" <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>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
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
 
 
Index ‹ java-programmer