Hash: SHA1

>> 1. Recently I started getting the following errors when downloads were
>> getting to 100%:
>> Temporary files error: File already freed
>> Freenet allows to remove or restart the download. If I restart it, it
>> immediately fails again with the same error. Restarting the client
>> doesn't seem to help.
> If you remove it, restart the node, and then re-add it from the URI, it still 
> breaks?

Removing the file, restarting the node and then readding the file
doesn't solve the problem. I either get an error outright or, sometimes,
the file remains stuck at 100% without ever being complete (waited for a
couple of hours for a really small (like, 250 Kb) file). Simply
restarting the node is not enough to fix both problems - the error
persists after restart.

> Is this easily reproducible, that is, under what circumstances does it 
> happen? 
> Does it only happen for certain files? For downloads that don't complete 
> until after the node has restarted?

Can't say I'd seen any definite correlation - but it *seems* to affect
smaller files more often (or maybe it's just that I download smaller
files more often? can't say for sure). I'll try to take notes next time
it happens.

Also, could it be related to the latest problems with last block
padding/encoding that were announced on the lists? I don't know in what
particular point in file the files I'm downloading were inserted, and
I'm afraid I won't be able to find it out.

> In general it should resume within a reasonable time. However, it could be 
> that the churn in your datastore is so high that many blocks have been lost. 
> Another complicating factor is that if the percentage is uncertain - that is 
> if it shows as "80%???" instead of "80%" in bold, it is downloading a 
> non-final layer of the file, and can fluctuate as it reaches new layers. Are 
> you sure this was not the case?

Yes, that's how it was in earlier versions - never had problems with
downloads being restarted in a reasonable time. Also, do my queue
downloads go into the store or into the cache? If it's the latter
(that's what I'd always assumed!), then churn could be ruled out - I
never had more than 1 Gb of queued downloads, while the cache size is
2.34 Gb, according to the stats page. The percentage was bold, so it was
 final, I'm absolutely sure of it.

> A third complicating factor is that the db4o branch should fix all this 
> anyway ... but recent bugs in trunk and other factors mean I haven't had much 
> time to work on it lately ...

Well, it's not something to loose sleep over. If db4o branch would fix
the problem, then it seems to be a good idea to concentrate on that.

Victor Denisov.
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to