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" ... 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. _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
