All extraction paths are tested by component in sequence from the root and in this case it is the last part giving problems. It is not a simple truncation because it uses the first 8 characters of the component plus the first three characters following the last dot (.doc). The code that tests the component still uses OpenFile (somehow I missed converting it) and that may be the problem. It only checks for two errors ERROR_FILENAME_EXCED_RANGE and ERROR_INVALID_NAME with any other error defaulting to ok (a bit optimistic). I will update it and add proper diagnostics (which won't help much if they are not sent to us). I have thought of making available some anonymous ftp space for such information but I don't like the chances of it staying clean. - Russell Peters -----Original Message----- From: delphizip-bounce@xxxxxxxxxxxxx [mailto:delphizip-bounce@xxxxxxxxxxxxx] On Behalf Of James Turner Sent: Monday, February 05, 2007 12:27 AM To: delphizip@xxxxxxxxxxxxx Subject: [delphizip] Re: Long filename not extracting properly Importance: High Assuming the Unzip DLL allocates buffers large enough for long file names, the most likely cause of the problem is an operating system issue. My guess woud be the API function CreateFile is failing (assuming CreateFile is used - it should be). If the Unzip DLL has sufficient diagnostics, this should be verified - the value of GetLastError will also be needed. I repeat, I have seen Windows have problems with very long file names such as "Tender Document 4.0 Terms and Conditions of Contract_IRB0001.doc". Generally, they should be avoided in favour of directories. To verify this try breaking it down to "Tender Document 4.0\Terms and Conditions of Contract\IRB0001.doc". My guess is that by replacing a couple of characters with slashes (forward or backward) file extraction will work correctly. What Version of Windows and what filing system are you using? -- James Turner ----- Original Message ----- From: "Randall Sell" <randallsell@xxxxxxxxx> To: <delphizip@xxxxxxxxxxxxx> Sent: Sunday, February 04, 2007 12:59 PM Subject: [delphizip] Re: Long filename not extracting properly > Well, after a lot more testing, it would appear that it may be related to > how the zip is created? Either that, or the order in which they are > extracted. The reason I suspect this is because I went and modified the > zip contents and changed it to a nice small filename: "x.zip" - and that > worked (phew). Then I went in, and added the big filename again - and it > worked as well. So now two files attached, "x,doc" and the big filename. > So maybe problem relates to the order in which things are extracted? And > if the first one (or the last one) happens to be a long name... hard to > say not being the code author. > anyway, that's what I know... Let's hope the client doesn't find it :) > > -rs > > > Randall Sell <randallsell@xxxxxxxxx> wrote: This is a very odd problem... > If I run via delphi debugger specifying my command line (which is then > extracted) it will work correctly. > > If I launch via Windows Explorer (file association is setup) then it > truncates this entry. but it is ONLY this one entry. All the other long > filenames are correct. > > If I don't use any sort of file associations, or command line params, and > just open the file via the EXE's file | Open - it fails there as well. > I'd be pretty happy to chalk it up to a bug in ZipMaster - but the bloody > thing works in some cases, and it works fine when I use the Demo1 app. so > I'm stumped. > > The full path to the file, when extracted is 136 chars: > D:\Documents and Settings\rj\Local > Settings\Temp\irb6AF.DHT\Attachments\Tender Document 4.0 Terms and > Conditions of Contract_IRB0001.doc > > -randall > ----------- 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.