On 2/09/2011 5:32 PM, Patrick Kolla-ten Venne wrote: > Strings in UTF8 will be the same length or longer. Never less length. > Upgrading Delphi won't change a thing. > As it has been said before, the issue is the zip header. > James Turner wrote that the length field in the zip header has a size of > one byte. Meaning you just can't store any longer names in there. Here, > I am confused now. I've written my own native zip structure reader code > (because for just listing contents and checking file size& crc32, > DelZip would be too much overhead), and my structure has FileNameLength > as a Word (and that code works, so I doubt that's a bug ;) ). Which > would allow longer filenames! > > So in my opinion, the limitation has to be elsewhere. > > Anyway, workarounds could be: > > If the user never uses the .zip himself, create an additional file with > metadata. You don't pass wildcards but the full list of files to > TZipMaster, right? So just add each single one with a different, > shorter, name (hash of name plus random number without path or something > like that) and have one additional file that relates this to real names, > which you would use in extraction. > >> Will using UTF8 help. I am using Delphi 2007, Will upgrading help. >> RegardsAllan Fernandes >> >> ----------- >> To unsubscribe from this list, send an empty e-mail >> message to: >> delphizip-request@xxxxxxxxxxxxx >> and put the word unsubscribe in the subject. > > > ----------- > To unsubscribe from this list, send an empty e-mail > message to: > delphizip-request@xxxxxxxxxxxxx > and put the word unsubscribe in the subject. It is not the zip format barrier (32 bits) that is being hit, it is the standard ms-dos MAX_PATH issue. Russell ----------- To unsubscribe from this list, send an empty e-mail message to: delphizip-request@xxxxxxxxxxxxx and put the word unsubscribe in the subject.