Re: Re: ZipArchive question

On Mar 12, 2016, at 2:01 PM, James Moe wrote:

On 03/12/2016 12:00 PM, Jeffry Killen wrote:

What is your OS? Would you provide a directory tree of the archive?

Client is Mac OSX 10.6x and the server is FreeBSD 10.1-RELEASE dir: upLoadTest

             |
     file:  testFile.txt
             |
    dir:  subdir --
               |
               file: testFile.txt

My thought was that one of the sub-directories was actually on a different volume. For instance, it is common that /usr is a separate volume than / even though they are presented as one single unit.

The possibility has already been presented that it could be an old version dating back to when floppies where in use and archives often had to be spread over multiple floppy disks. I am attempting to find out if the built in compression in Mac can be reconfigured to use a different method, if, in fact that is the source of the problem. But there may be other obscure technical reasons for the problem. It seemed like I had this working on a basic level at one time, but now I am not even getting a single compressed file to decompress. I have already had to deal with return values from ZipArchive methods and am pretty sure I have not fallen into the trap where boolean false converts to 0 and can be misinterpreted as an integer value and give a wrong result. For instance, I have encountered a situation where referencing an indexed array item: $array[false] == $array[0], and integer return value from ziparchive::open (0) is misinterpreted. In error codes, a return value of (int) 0 indicates no error. But it returns false on failure as I remember, and the actual integer indicating the error is not available until close is called.