-----BEGIN PGP SIGNED MESSAGE----- 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. Regards, Victor Denisov. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQUDP1O5++4rTuI0RAo1XAJ4o4WNS8wqiVtXaJXhGpRSc9TVzNgCg4GDG l3oYqSw7NqjAuLJFd+V60dM= =XJyI -----END PGP SIGNATURE-----
