| From: | Aaron Optimizer Digulla |
| Date: | 11 Sep 2000 at 08:53:38 |
| Subject: | Re: [RE: AMIOPEN: AmiPak] |
On Thu, Sep 07, 2000 at 01:57:57PM +0200, Victor I. Haaz wrote:
> >The most user-friendly way I know of handling compression from a user
> >perspective is to simply give them a tool to compress directories in
> >place, converting `my_folder/' into `my_folder.tgz' (or .amp or .zip
> >or whatever). If they choose to unpack it again, then everything
> >should be exactly as they left it - dates, links, everything.
>
> One thing I didn't seen it mentioned here:
>
> There is a tool on the classic OS, which mounts archives as a new device
> ("archive-filename:"), so all the system can access any files within trans-
> parently. (It's sadly read-only, AIK).
A much better solution would be if you can "cd" into an archive. I
also thought about automatically creating a directory with the same
name (without the extension) but that has some drawbacks:
- What if there already is a directory with that name ?
- Copying archives would also create directories.
The source of the problems is that an archive would become a hybrid:
It should behave like a file when you copy it (ie. no need to specify
to copy it recursively) but also like a directory which you can enter,
list, etc.
Maybe the best solution would be to drop the -r option for cp.
This way, one would not have to explain users that they must use
special options to copy and delete a directory (which you also
don't need when you move or rename it !). This way, files would
be much more like directories and archive-directories would be
much more simple.
> And maybe it would be needed to differenciate between one-file archives
> and multi-file archives. Because the former can be hadled as the file
> within itself, while the latter may need a pop-up file-requester, or the like,
> upon use by user/app.
This is not really necessary. Here are the cases:
- You have a simple compressed file. You will want to access the archive
(ie. no automatic decompression when you copy it somewhere else) and
the contents. So you will have foo.gz and foo.gz/foo.
- You have a whole directory tree inside an archive. Now you have
foo.zip, foo.zip/foo/...
- You have an archive inside an archive (ie. .tar.gz). Now you
have foo.tar.gz which contains foo.tar which contains foo.
This might look like overkill (because you can "see" foo.tar)
but it will make the transparent decompression much more simple
if one doesn't have to take shortcuts into account.
Another solution *migth* be to offer foo.tar.gz/foo.tar and
foo.tar.gz/foo (so you can have to archive inside the archive
and the contents of the archive inside the archive) but that
makes the transparent decompression more complex and it
also might cause problems (because if we have a "good" filesystem,
then the extensions of the files have no real meaning, ie.
you can have a ZIP archive with any extension and the filesystem
will still recognise it - no crashes like on Windows when you
rename a .BMP into a .EXE).