|[hatari-devel] improvement ideas for zip files|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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
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 directories.
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.
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"
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.
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 ?)