#47 when using -FF unicode file names "corrupted"' as GPBF 11 wrongfully set to 0.

[al assou]

utf-8 filenames of a zip are spoiled when using -FF on it.

reproducibility:
make a zip (with zip or 7-zip) including a file with non-ascii name on an utf8-system:
ex) $ zip /test.zip /été.txt

try to fix it with -FF:
ex) $ zip -v -FF /test.zip --out /testFixed.zip

unzip or open the "fixed" testFixed.zip with a zip-viewer (7-zip).
It appears the name of the zipped été.txt file inside testFixed.zip turned to:
├®t├®.txt

what happens:
whenever using -FF on a zip with utf-8 filenames in the header, the Bit 11 UTF8 Flag is forcefully and wrongfully forced to 0 (except, in an paradoxical manner, if the extra field is used to store the utf8 name).

versions tested:
3.0 and 3.1c both with UNICODE_SUPPORT on cygwin.

cause:
To deal with local headers, zip_fixnew() call zipcopy() which always set localz->uname to NULL when fix==2, then to rewrite the headers call upon putlocal().
putlocal() checks upon the fact that z->uname is not null, otherwise it decides to "clear UTF-8 bit as not needed ".

possible solutions: either initialize uname when fix==2 if the name is utf8, or suppress the "unflagging" of bit 11 in putlocal() whenever uname=0.

[Ed Gordon]

This is actually a known deficiency that we had forgotten about. This was intentional to simplify -FF implementation at the time. Fixing -FF to handle UTF-8 properly is approaching the top of the list and should be addressed in the current Zip 3.1e beta thread in the next couple weeks. Thanks for the reminder.