> 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. > 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. 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. _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
