|Re: [hatari-devel] improvement ideas for zip files|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On lauantai 25 elokuu 2012, Nicolas Pomarède wrote:
> What do you think ? Anyone feeling like giving this a look, Eero maybe ?
> (as I think you're the one that worked on zip file support ?)
I've never used zip files with Hatari except for the one time when I
refactored the fileselector code and had to test & fix also the zip part.
Even after my refactoring the file selection code is still a monster
and the zip support is one large reason for that.
If you would ask me I would solve this problem by removing the zip
Gzip does better compression for image files and should be about as well
supported as .zip format (nowadays). For zips which contain other things
than image(s), one can use the zip2st script.
> while using some disk image stored in zip files, I noticed a few things
> that could be improved :
> Let's say you have "image.zip" in directory "ST/games/" and "image.zip"
> contains "disk1.st" and "disk2.st".
> 1) If you insert disk1.st into drive A and then later go to floppy menu
> to insert disk2.st, the fileselector starts from "ST/games/", not from
> the zip you opened the last time you changed drive A content. When you
> have a directory with hundred of zip, it takes time to scroll until you
> can go into image.zip again.
> 2) When saving a memory snapshot, same problem happens : if you saved
> with disk1.st inserted for example, next time you access the floppy
> menu, you won't start from the content of image.zip, but one level above
> in "ST/games/"
As Matthias mentioned, fsel just jumping to the current file would be
a large improvement. I might take a look at that at some point, but
I'm not going to touch the zip stuff.
(If you want to look into it, I think best starting point might be
refactoring the code for getting the current (zip or normal) directory
content out of that monster function.)
> 3) When starting from the command line with --disk-a option, if a zip
> file is given, it will insert the first recognized disk image in drive
> A, which is fine. But when several images are available, it could be
> handy to be able to give the name of the disk image to use from the zip
> There're many ways to create a full path name when combining an archive
> file and the files into this archive file, this is used in many virtual
> file system solution today to navigate inside archives as a normal
> directory without having to worry about extracting it first.
> Maybe we could extend Hatari's path handling to have things like
> "path1/path2/image.zip/disk2.st" ?
> In that case the file name would be the last part of the full path, and
> all the parts before the file name would be considered as a global path
> (as it is today). Except we would add an intermediate parsing level to
> check if this global path contains archive files, not just real
> So, let's say we have a path to resolve, we split it with '/' as
> boundary, and for each part, we check if we have a real directory or a
> file. If it's a file with zip extension, then we try to open it as a
> zipfile and continue from there.
Simpler would be just to use some special character like ':' to
indicate that rest of the file name is inside the first part.
> A generic solution would be to allow
> "path1/image.zip/path2/path3/disk.st" ; if the code can be written in a
> generic/recursive way, maybe it could even be possible to handle complex
> path like "path1/image.zip/path2/image2.zip/path3/disk.st"
If you want zip within zip support, you need to expand zip.c to
support that (extract the contained zip file from outer zip file
etc). I don't see a point in doing that, besides complicating
zip.c a lot, it would complicate the file selection code too.
Zip files containing other zip files are just annoying. IMHO one
should complain about them instead of accomodating them. :-)
> But even a simpler solution where only the first level of the zip is
> used (no path name inside the zip) and only one zip file into the path
> would be good.