On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > On Wed, Nov 01, 2006 at 08:06:59PM +0100, bbackde at googlemail.com wrote: > > But what to tell the user now? The key you know is unusable and > > corrupted. Give up... > > Well yes, the key is corrupted. It has been modified by the user and is > no longer usable, just as if he had changed part of the actual CHK. > > Workarounds are of course possible if I implement the list-manifest > command. It would even be possible for the node to detect that there is > only one element in the manifest and redirect to that. That's a hack, > but only a very small one. > > But as you pointed out, the big picture is not back compatibility, it's > what we want to do normally. > > Do I have your full support for forcing keys to be fetched exactly as > inserted? I.e. if a key is inserted as a pure CHK, and then fetched with > a bogus filename, Fred will return an error including a URI with the > bogus filename stripped?
You would have my full support for something like this. As long as the node gives some hint about the correct uri/name if possible. I think this is what you meant. This would allow to implement a client that is easily useable. And a good documentation is needed for that :) > > > > On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >On Wed, Nov 01, 2006 at 12:08:37PM +0100, bbackde at googlemail.com wrote: > > >> >From frost board unsuccessful: > > >> > > >> ----- Rattus norvegicus at cHS+d02GNcw2Y68jyg2kIgAQLjI ----- 2006.11.01 - > > >> 09:28:31GMT ----- > > >> > > >> Currently comes up in the node interface as "Not in archive" > > >> > > >> > > >CHK at > > >XW6IcA5UDIqd1RaVDKvaCB-C4wSbN6KOaaN~v8j04Fg,XE73xs1i3AsyxDo-h6e3Z-Sk5-dDSIwITsv9yz4bdqo,AAEC--8/SomeFilename.zip > > > > > >If this was inserted without a filename, it would not produce this > > >error. In future it may produce "Too many meta-strings" (or path > > >elements?), but right now it would Just Work. > > > > > >The problem therefore is that it was inserted with a different filename > > >to the one that it was requested as. > > > > > > > > >-----BEGIN PGP SIGNATURE----- > > >Version: GnuPG v1.4.5 (GNU/Linux) > > > > > >iD8DBQFFSN2/A9rUluQ9pFARAjfYAJ4i5MC6CHlj7WPXvlU6Gmjr9JheIQCgqyPD > > >ZlAiU26llS9q3ccNT764f7s= > > >=zu96 > > >-----END PGP SIGNATURE----- > > > > > > > > >_______________________________________________ > > >Support mailing list > > >Support at freenetproject.org > > >http://news.gmane.org/gmane.network.freenet.support > > >Unsubscribe at > > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > > >Or mailto:support-request at freenetproject.org?subject=unsubscribe > > > > > > > > _______________________________________________ > > Support mailing list > > Support at freenetproject.org > > http://news.gmane.org/gmane.network.freenet.support > > Unsubscribe at > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > > Or mailto:support-request at freenetproject.org?subject=unsubscribe > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFSPocA9rUluQ9pFARAuQgAJ9Lf/p4H+NhMWYiImfoBDaeYkf+xQCeMls9 > bkKWyR2T0bh3IRKQMXbKk1o= > =7ynH > -----END PGP SIGNATURE----- > > > _______________________________________________ > Support mailing list > Support at freenetproject.org > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:support-request at freenetproject.org?subject=unsubscribe > >
