On Thu, Sep 18, 2003 at 07:39:58PM +0200, Michael Schierl wrote: > On Thu, 18 Sep 2003 15:57:20 +0100, Gordan wrote: > > > On Wednesday 17 September 2003 16:42, fish wrote: > > > >>> I seem to remember seeing this mentioned on this list some time ago, but > >>> I can't remember the details. I tried uploading a zip, then accessing > >>> contents using mycontainer.zip//myfile but that doesn't seem to work. > >> > >> Assuming that the mime type of the file you inserted is 'application/zip', > >> it should work (disclaimer: that rougly translates to 'it works for me'). > >> If it isn't, then, uhm, it won't :). Beyond that, FIW v0.07 and Fishtools > >> 3.1.0-alpha20 both, afaik, support containering sites. > > > > OK, I have a file test.zip. It contains two files, test.html and test.txt. I > > uploaded it using FIW 0.07, and it's key is: > > > > [EMAIL PROTECTED],ZSuhFw6jeLEj2AXY0ImzRA/test.zip > > > > It is verified to be retrievable, and the mime type is application/zip. > > However, saying: > > > > [EMAIL PROTECTED],ZSuhFw6jeLEj2AXY0ImzRA/test.zip//test.html > > > > returns a message saying that the file doesn't exist. > > Try to let FIW build the container for you or use the "insert a file/NIM" > function for inserting it (into a CHK key, *not* into any other key > type![1]); insterting it inside a freesite does not work... There are some > strange assumptions made on the metadata for containers (e.g. there *must* > be a Info.Format in the manifest on the "final" key, but *may not* be one > in any intermediate manifests. > > If you upload a .zip as part of a freesite, the Info.Format gets into the > site's mapfile instead of the mapfile of the final key, so containers > simply used as .zip do not work. > > > What gives? I'm using unstable 6194. > > Container support is really unstable. there are at least two bugs in it > still - one that assumes that a piece of metadata whose "first" (according > to the hash function) entry is application/zip is a container; if it is not > (as usually), you cannot request any files from the site. Renaming that zip > file (e.g. from a_file.zip to a_pile.zip) helps. The second one makes > Fproxy throw NPEs if you have a key have a metadata redirect to a file > inside a container. See the devl archives for that two bug reports (by me, > but no reaction; these bugs seem to be "low priority" ...
Test cases? > > mihi > > [1] if you use another key type and the container is big, it will create a > redirect into that key (with Info.Format) to a CHK without metadata. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
