Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#17 Zip 3.0f trouble with non-ascii chars in file names

closed-fixed
nobody
None
5
2013-03-01
2007-10-26
Willus
No

I'm running zip 3.0f that I compiled in CentOS Linux (4.3) using gcc 3.4.5--standard compile. It aborts when you ask it to zip a file that has a non-ASCII character (in this case, 0xE6) in the file name. Zip 2.3, on the other hand, had no problem with this same case. If you do a full install of CentOS (ALL packages), this file is in the folder /usr/share/doc/man-pages-da-0.1.1.

Discussion

  • Willus
    Willus
    2007-10-29

    Logged In: YES
    user_id=681780
    Originator: YES

    I've now attached a zip archive with an example file that causes the problem. The file was created with the C program listed below. If I try to zip this into a new archive with zip 3.0f (CentOS 4.3, gcc 3.4.5, x86-64 (Opteron)), I get this message:

    zip error: Interrupted (aborting)

    Interesting notes: A similar example worked okay on a different Linux (2.4.x kernel). Also, if the archive already exists and already has the offending file name in it, zip 3.0f appears to update it successfully.

    I have verified that when I unzip the file from the attached archive and then try to re-zip it into a new archive with zip 3.0f, I get the bug.

    #include <stdio.h>
    #include <string.h>

    void main(void)

    {
    char filename[256];
    FILE *f;

    strcpy(filename,"abcdef.txt");
    filename[2]=0xe6;
    f=fopen(filename,"w");
    fprintf(f,"hello\n");
    fclose(f);
    }

    File Added: nonascii.zip

     
  • Willus
    Willus
    2007-10-29

    Zip archive with offending file

     
    Attachments
  • Willus
    Willus
    2007-10-30

    Logged In: YES
    user_id=681780
    Originator: YES

    I did some investigating and found that the problem is that the CentOS mbstowcs() function is returning -1 when trying to convert the offending file name, and this causes local_to_wide_string() to return NULL, which causes local_to_utf8_string() to return NULL which means f->uname gets NULL and is_ascii_string() gets passed a NULL pointer and causes a SIGSEGV. This mod to local_to_utf8_string() is one possible fix:

    char *local_to_utf8_string(local_string)
    char *local_string;
    {
    zwchar *wide_string = local_to_wide_string(local_string);
    char *utf8_string;
    if (wide_string==NULL)
    {
    utf8_string=malloc(strlen(local_string)+1);
    if (utf8_string!=NULL)
    strcpy(utf8_string,local_string);
    }
    else
    {
    utf8_string = wide_to_utf8_string(wide_string);
    free(wide_string);
    }
    return utf8_string;
    }

     
  • Ed Gordon
    Ed Gordon
    2008-02-10

    Logged In: YES
    user_id=1172496
    Originator: NO

    This may be fixed in Zip 3.0g which has just been posted.

     
  • Steven Schweda
    Steven Schweda
    2013-03-01

    • status: open --> closed-fixed