On Mon, Apr 02, 2001 at 05:12:16PM -0500, Brandon wrote: > > > It appears to be a deliberate design decision. In SimplifiedClient (fproxy) > > and InsertClient both. > > SimplifiedClient doesn't generate CHKs. That's done by the ClientUtil > library, I believe, so it's no wonder that both do it the same way.
SimplifiedClient does instantiate a ClientCHK (using its own method, not ClientUtil). It uses the ClientCHK constructor that takes a stream and a length as arguments. It passes the stream and length of the data Bucket. So if the data Bucket's empty.. InsertClient does this too (the relevant code is identical). > > So, I think we need to change this so that encryption keys for CHKs are > > generated from the entire file. We might as well go ahead and fix it > > in the current Fred. The only thing we lose is a few missed CHK > > collisions. > > If you make it take metadata into account when you generate the CHK then > you won't get CHK collisions for the same file but different > metadata. That's pretty important as we don't want people inserting the > same thing over and over again under different names if it's possibly > avoidable. The only time that this is actually problematic is when you > have control documents referenced by CHKs. In this situation the metadata > is actually being used to hold the data and there is no data section, so > determining if two files are the same requires using the metadata and not > the data. Any two non-identical files will have different CHKs when inserted. The situation we have now is that two different files with the same data section but differing metadata will have the same encryption key for the CHK. The 2 CHKs will still be different. This is because for some strange reason the encryption key is generated from the data section only instead of the entire file. > One way to solve this problem is to calculate CHKs with metadata+data and > not give normal files any metadata (have a redirect contain the metadata > for the file and the URI for the content). Another way is to calculate > CHKs with just data and put the control document in the data section. > > Perhaps someone can see a creative solution to this one. It seems to me to > be a pretty insoluable trade-off in functionality. We don't need a creative solution. There is no trade-off here. -- # tavin cole # if code is law, then Freenet is a crowded theater _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
