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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
