On Wed, Jan 29, 2003 at 03:16:33PM +0100, Michael Schierl wrote: > Gianni Johansson schrieb: > > [mainport.params.servlet.7.params.sfDoParanoidChecks=false] > > > This is not a good idea. Leave it on. I routinely see corrupted blocks. > > Do they have metadata? If thwy don't, it should help to declare all > corrupted blocks with metadata as non-corrupted. We are trying to determine the difficulty of detecting metadata and if any is found, not checking individual blocks at all. > > > > If > > we catch them they can be retried or at least ignored. If you turn off > > checking then in the best case the corrupted data will be used to > > reconstruct > > the file and will be caught by the new checksuming code at the very end of > > the download.. > > Getting corrupted data with no warning is nothing new on Freenet. So I'd > only use files that have their own checksum (e. g. Zip files) Not true. It should be very rare now. And I want to hear about cases of it. Incidentally, files inserted using the _current_ command line insertor have an SHA-1 checksum added automatically, which is checked by the command line downloader and by fproxy. > > > For old SplitFiles there is no checksum, and the user will > > get corrupted data with no warning. > > is that checksum generated by the FEC code or does the client have to > create it himself? So that will be the next thing that will delay next > FIW version if I have to add code for that. > > > Why not just add a "Skip block checks" option to the UI which is off by > > default and can be enabled by the user to get bad files? > > Another idea. Or switching it on automatically, if you have as many > failures that you cannot complete the file and no successful block. I don't get it. > > > If anyone out there wants to go after the root problem of *why* we are > > getting corrupted blocks, here's your chance to be a Freenet hero. > > ;-) it's caused by the datastore bug. As it cannot live in datastores > any longer, it lives in splitfiles now. Um... there is no datastore bug. > > > > I understand mihi is frustrated, but the idea of trying to support > > splitfiles > > with metadata is just wrong. There is no reason to do it. > > Okay, you have the list of sites in my previous post. Download all > splitfiles of them and reinsert them properly with at least HTL 20 onto > your site. (that will also help the original authors, as they get > KeyCollisions for the blocks when FIW is fixed.) When you are finished, > come again and say "no reason" again. Mostly, this would be illegal. > > > It is hard and it complicates the code. > > ignoring it and swithcing all specialties off should not be the problem. > Simply show a warning in the UI then... Uh huh. "Freenet may cause the file to be corrupted. We cannot do anything about this because the FIW author won't change one line of code.". > > > Why doesn't someone just fix his code? > > I'll fix it, but not that week, not next week and most probably not the > week after. > > And fixing the code does not help for the freesites that are already > inserted. > > mihi
-- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at ICTHUS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030129/2ca37a6d/attachment.pgp>
