Hi,

I had a closer look at the frost/keypool/*tmp-chunk* files while
download a big file, which was splitted into 100 chunks.

I noticed, that chunks in the middle were zero bytes or less than the
"SplitFile.Blocksize" and were not growing anymore, while new chunks were
created and grew.

I think, that the following error messages belongs to that fact, that
some chunks were dead:

one of them:

---cut-on---
Jan 17, 2003 5:02:22 PM
(freenet.node.ds.FSDataStoreElement$KeyInputStreamImpl, Finalizer):
Please close() me manually in finalizer: Key: <some_long_key> Buffer: 
freenet.fs.dir.NativeFSDirectory$ExternalNativeBuffer@3b88f2 New: true ( 0 of 1025 
read)
java.lang.IllegalStateException: unclosed
        at 
freenet.node.ds.FSDataStoreElement$KeyInputStreamImpl.finalize(FSDataStoreElement.java:314)
        at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
        at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:86)
        at java.lang.ref.Finalizer.access$100(Finalizer.java:17)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:163)
===============
StateChain started at Fri Jan 17 16:59:32 CET 2003
Current state: Request Done @ <some_short_key>
---cut-off---

manually closing and restarting freenet gave the following information:

---cut-on---
Jan 17, 2003 5:08:42 PM (freenet.node.rt.DataObjectRoutingStore, main):
Removing orphaned property 0x0 : <some_long_key>
---cut-off---

This is truly a bad bug, because if all chunks are downloaded, the file
is assumed to be ready to be copied to the download directory, right?

Does Java have no bugtracking system to force closing those elements
automatically?

What would be a workaround, until this bug is not resolved?

cu
Sascha
-- 
GNU Linux | If I said you had a beautiful body - would you hold it
2.4.19-cr | against me? I am no longer infected! -- John Cleese,
on a      | Monty Python   
i586      | 
          | 
          | 

_______________________________________________
support mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support

Reply via email to