AmiKit for linux: errors in filesystem

[jbl007]

Hi #?

I recently installed the linux version of AmiKit to use with fs-uae. It works very well.
Because there are more than 38.000 files and this could be bad for the host filesystem (and the ssd) I decided to make a .hdf, but I got some errors while copying all the files using dopus.
I took a closer look and found 314 files which can't be used inside the emulated Amiga. http://paste.debian.net/plain/72990
These files are invisible to the amiga, but if you try to copy the directories, you get filesystem errors.
As a workaround I deleted the files, but it would be nice to have this fixed in the next release of AmiKit.

I don't know if the windows- and mac versions are affected as well.

[_ThEcRoW]

What workbench files are you using for the instalation?. I remember having issues when using the amiga forever dvd for the installation, the amikit installer would copy certain files with wrong file permissions, and the only solution was to manually modify file permissions back.

[jbl007]

Thanks for your reply, but I think this problem is different from yours. It is not about the permissions, it's about the encoding of the file-/directory names. In addition theses file aren't from the cd, they are inside the archive you can download.

Windows version works file btw., now I'm using these files.

[FrodeSolheim]

I checked the zip file - it isn't broken as such. Unfortunately, there wasn't originally a standard for what character set to have in zip files. So using non-ASCII file names are generally unreliable. Nowadays, many programs support using unicode names in zip files, but of course Windows Explorer does not (last time I checked...).

But anyway, in this zip file, file names are stored with ISO-8859-1 encoding, so either the unzip program must assume that, or use heuristics to guess it, or allow the user to specify ISO-8859-1 as source encoding when extracting the names :-/

Here's a python snipped to verify (the printed file names look good):

from zipfile import ZipFile
zf = ZipFile("AmiKit.zip")
for name in zf.namelist(): 
    for c in name:
        if ord(c) > 127:
            print(name.decode("ISO-8859-1"))
            break

[FrodeSolheim]

In Linux (and probably OS X too), you can unzip it like this:

unzip -I latin1 ../../Public/AmiKit.zip

(On Windows, Windows Explorer will just always assume CP437, so that won't work. The 7-Zip GUI program does not seem to have a character set override either).

[jbl007]

Ok, file names are stored with ISO-8859-1, thanks for pointing that out.

Originally Posted by FrodeSolheim

In Linux (and probably OS X too), you can unzip it like this:

unzip -I latin1 ../../Public/AmiKit.zip

Hm... my unzip doesn't know "-I" and it is not documented. What unzip version do you use?

The 7-Zip GUI program does not seem to have a character set override either).

At least "7z" seems to be the only program, which "guesses" the correct encoding. (tested using this). I tried various archivers, some of them display the correct file names, but all of them failed when extracting.

[FrodeSolheim]

$ unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
...

[jbl007]

Ubuntu only specific patch
(debian/patches/06-unzip60-alt-iconv-utf8)