[hatari-devel] improvement ideas for zip files

[ Thread Index | Date 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 in "ST/games/"

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 file.

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 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 ?)


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/