[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

what looks like a nice Windows-only bug in 0.6.1: symptoms java.io.IOException: Unable to rename shadow file



[I'm thinking that a searchable version of the mailing list archives would
be a Good Thing].

I'm testing my Ozone 0.6.1 code by breaking things, and I'm finding that no
transactions will successfully abort. I get:

[warn] (341) TransactionManager: Aborting transaction failed: ta(-123)
    java.io.IOException: Unable to rename shadow file.
     at org.ozoneDB.core.wizardStore.Cluster.restoreShadow(Cluster.java:280)
     at org.ozoneDB.core.wizardStore.Cluster.abort(Cluster.java:197)
     at
org.ozoneDB.core.wizardStore.ClusterStore.abortCluster(ClusterStore.java:611
)
     at
org.ozoneDB.core.wizardStore.WizardStore.abortTransaction(WizardStore.java:7
05)
     at org.ozoneDB.core.Transaction.abort(Transaction.java:338)
     at
org.ozoneDB.core.TransactionManager.abortTransaction(TransactionManager.java
:519)
     at
org.ozoneDB.core.TransactionManager.completeTransaction(TransactionManager.j
ava:339)
     at
org.ozoneDB.core.TransactionManager.handleCommand(TransactionManager.java:24
9)
     at
org.ozoneDB.core.InvokeServer.handleClientEvent(InvokeServer.java:76)
     at
org.ozoneDB.DxLib.net.DxMultiServerClient.run(DxMultiServerClient.java:44)
     at java.lang.Thread.run(Thread.java:484)

[error](341) TransactionManager: handleCommand(): java.io.IOException:
Unable to rename shadow file.
    java.io.IOException: Unable to rename shadow file.
     at org.ozoneDB.core.wizardStore.Cluster.restoreShadow(Cluster.java:280)
     at org.ozoneDB.core.wizardStore.Cluster.abort(Cluster.java:197)
     at
org.ozoneDB.core.wizardStore.ClusterStore.abortCluster(ClusterStore.java:611
)
     at
org.ozoneDB.core.wizardStore.WizardStore.abortTransaction(WizardStore.java:7
05)
     at org.ozoneDB.core.Transaction.abort(Transaction.java:338)
     at
org.ozoneDB.core.TransactionManager.abortTransaction(TransactionManager.java
:519)
     at
org.ozoneDB.core.TransactionManager.completeTransaction(TransactionManager.j
ava:339)
     at
org.ozoneDB.core.TransactionManager.handleCommand(TransactionManager.java:24
9)
     at
org.ozoneDB.core.InvokeServer.handleClientEvent(InvokeServer.java:76)
     at
org.ozoneDB.DxLib.net.DxMultiServerClient.run(DxMultiServerClient.java:44)
     at java.lang.Thread.run(Thread.java:484)

(or words to that effect). Going digging, I find that
org.ozoneDB.core.wizardStore.Cluster.restoreShadow() looks pretty much like
this:

        String basename = clusterStore.basename( clusterID );
        File orig = new File( basename + ClusterStore.POSTFIX_CLUSTER );
        File shadow = new File( basename + ClusterStore.POSTFIX_SHADOW );
        if (!shadow.renameTo( orig )) {
            throw new IOException( "Unable to rename shadow file." );
        }

Based on my understanding of the rest of the shadow/transaction code in
org.ozoneDB.core.wizardStore.Cluster, the cluster file is copied at the
start of the transaction such that a shadow and a cluster file exist (105.cl
and 105.sh, for example). When the transaction is committed, the shadow file
is deleted; if the transaction is aborted, the shadow file is used to
overwrite the cluster file. Thus both files exist while the transaction is
taking place.

The problem here is that File.renameTo(File) will always do nothing and
return false in Windows if both files exist. (I will admit to developing on
a Windows 98 machine; my excuse is that it's pretty much necessary for the
game business; I haven't yet tested this on a Win2000 box, but I will later.
My current tests use Java1.3 as a VM).

I can suggest some workarounds here -- deleting the cluster file first being
the obvious and rather ugly one -- but as I can't immediately think of
anything that isn't ugly and wouldn't require extra clean-up initialization
code to protect from a crash occurring mid-way through a procedure, I
thought I'd open it to the room and take suggestions.

Reason
http://www.exratio.com/