[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what looks like a nice Windows-only bug in 0.6.1: symptoms java.io.IOException: Unable to rename shadow file
On Fri, 23 Mar 2001, Reason wrote:
> [I'm thinking that a searchable version of the mailing list archives would
> be a Good Thing].
Somebody did register the two ozone list in a mail list archive site. Maybe he
can give us a link where we can find this (hopefully searchable) archive ???
> 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.
correct.
>
> The problem here is that File.renameTo(File) will always do nothing and
> return false in Windows if both files exist.
Ahhhhh... I love this 'write once, run...' :(
> (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.
I will take a look at it tomorrow. I will probably implement the simple
delete-before-replace solution. Thanks for hunting down this bug, Reason.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com