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