From owner-freebsd-hackers  Tue Jan 16 09:47:45 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA28422
          for hackers-outgoing; Tue, 16 Jan 1996 09:47:45 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA28417
          for <Hackers@freebsd.org>; Tue, 16 Jan 1996 09:47:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA10782; Tue, 16 Jan 1996 09:47:03 -0800
To: Nate Williams <nate@sri.MT.net>
cc: Michael Smith <msmith@atrad.adelaide.edu.au>,
        tnaggs@cddotdot.mikom.csir.co.za, Hackers@freebsd.org
Subject: Re: FBSD 2.1 
In-reply-to: Your message of "Tue, 16 Jan 1996 10:24:21 MST."
             <199601161724.KAA04736@rocky.sri.MT.net> 
Date: Tue, 16 Jan 1996 09:47:03 -0800
Message-ID: <10780.821814423@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk

> Oooh, getting Snazzy here.  Does this mean you want it in C++ now?
> *grin*

Naw, ADA will do.  Anyone seen the FreeBSD ADA compiler around?  He
can do this as multiple tasks. :-)

> Since the ZIP format doesn't have a concept of links, it will only store
> filenames.  Unfortunately, this means that we can't do symlinks inside
> of zip files. :(

Heh?  I actually added the 3rd parameter after seeing the following in
the help for `zip'

  -y   store symbolic links as the link instead of the referenced file

> Is this going to be a show stopper?

Not at all, I was just trying to give full coverage to what I perceived
the `zip spec'.

> Hmm, the above 2 could get interesting.  I'm not sure how you'd do that,
> in the same way I'm not sure how you'd do that with files inside a tar
> file.

You're a clever boy, you'll figure it out.. :-)

Actually, I could be a lot nicer of a guy and revamp my internal
structure to pass FILE*'s around rather than fds.  It would be a small
gritch, but I could do it.  This would allow you to implement the
above rather trivially with funopen().

OK, how's this:

FILE	*zip_fopen(ZIP_t zp, char *fname)

Return a file pointer for an entry in a zip file.  When an fread from
the new fp returns EOF, a zip_fclose() on the fp should be done to
clean up any state lying around.

Returns new fp on success or NULL if entry not found/open failed.

int	zip_fdclose(ZIP_t zp, FILE *fd)

Close a file pointer previously returned by zip_fopen().
Returns 0 on success, -1 on error.

?
					Jordan