>> > when specifying ClientPut/RemoveLocalKey=true, does fred remove the stored >> > key (chk) BEFORE or AFTER trying an insert? >> >> If you removed the key after insertion, then the insertion will not >> have worked, because the key will be gone. So that wouldn't make much >> sense.
i think about RLK=t like a GenerateCHK - doing some stuff, looking if it works, but not performing any (permanent) operations on the store itself - i thought this was the intention of this field? if not, what *is* it's intention? >> > experiments with build 618 (btw - the new layout (bullets, small title frame, >> > typo) sucks in my opinion) revealed, that a ClientPut succeeds with >> > RemoveLocalKey=true, even if that key *already existed*! this leaves me to >> > think that the *old* key is removed before the *new* key is stored, leading >> > to no key collision. >> >> Well, yeah. That's kind of the point. sorry, my english linguistic instinct is not that good, i know what that means, but not what you intent with your statement? >> > the IMHO correct way would be to remove the *new* key *right after* it has >> > been inserted, and if such a key already exsits when trying the insert, >> > returning a KeyCollision! >> >> But then you'd be deleting keys from your data store and not replacing >> them. Given that the point of the RemoveLocalKey option is to >> improve propagation of your keys, deleting from your data store >> afterward seems to be a step backward. >> >> If your goal is to remove all traces of the key from your data store >> after insertion to "hide your tracks", then I think you should consider >> stopping your node and running "rm -rf store_*" or "DELTREE store_*". >> And make sure you're using a transient node for this purpose, not a >> permanent one. (( linebreak inserted for us little suckers :p )) >Um, you have no plausible deniability if you run a transient node... if >it's in your datastore and you are transient, you must have put it >there. If it's in your datastore and you are permanent, it probably came >from another node, and you have no reason to know what it is.. greatly >improving your legal position in most sane places (IANAL, but this is >well known to be one of the major principles on which freenet is based). you are right. but i do not concern about guilt, just about a "clean and defined specification and implementation" of the RemoveLocalKey field. the fndocs/* are way before stone age and not a very relyable source of information when trying to implement tools at the cutting edge - is there a more up- to-date version of FCP and possibly FEC around or at least a "diff on the information" concerning these? ____________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
