Re: Re: ZipArchive headache

On May 6, 2015, at 3:43 PM, Maciek Sokolewicz wrote:

On 6-5-2015 22:06, Jeffry Killen wrote:

On May 6, 2015, at 11:35 AM, Jeffry Killen wrote:

On May 6, 2015, at 9:52 AM, Jeffry Killen wrote:

On May 6, 2015, at 5:45 AM, Christoph Becker wrote:

Hi Jeffry, Am 06.05.2015 um 02:41 schrieb Jeffry Killen:

On May 5, 2015, at 3:36 PM, Christoph Becker wrote:

Jeffry Killen wrote:

1: ZipArchive::ER_MULTIDISK|Multi-disk zip archives not supported: test-2.zip

I just found <https://bugs.php.net/bug.php?id=60348>, where the same meaningless result was returned. It turned out to be related to symlinked directories. Can you please verify, Jeffry?

Well, I haven't worked with any symlinked directories. And I have not worked with any linked or aliased resources in a web server context or otherwise. So it would require me to get familiar with that scenario first, to test it out. (if that is what you mean by verify)

A simple verification would be to use realpath(getcwd()) instead of getcwd(). BTW: usually you should "reply to all" – the discussion might be interesting for others, too. :)

Thank you: You suggestion for verification is simple enough, I am sorry, I sometimes am distracted and neglect to reply all JK

here is the revised code using realpath(getcwd()) At the bottom is the same result; else if($_GET['newArchAlt']) {

    //header('Content-Type: text/plain');
    //print $_GET['newArchAlt'];
    //exit;
    require_once("php/zpArchConst.php");
    //$_constER;
    $_alt = new ZipArchive();
    $_ret = $_alt->open(realpath(getcwd()).'/'.$_GET['newArchAlt'],

ZipArchive::CREATE);

    header('Content-Type: text/plain');
    print $_ret.': '.$_constER[$_ret].":  ".$_GET['newArchAlt'];
    exit;

1: ZipArchive::ER_MULTIDISK|Multi-disk zip archives not supported: test-2.zip JK

Here is more: The code that DOES work and code that gives the same error in a synchronous post context $_retStr = array(); $_ret = ''; if($_POST) { // This works if($_POST['clsDef'] == 'false') // <<< radio button used to choose code to use

     {
      require_once("php/zpArchConst.php");
      $_alt = new ZipArchive();
      $_ret = $_alt->open(getcwd().'/'.$_POST['mkZp'],

ZipArchive::CREATE);

      if($_ret !== true)
        {
         $_retStr['error'] = $_ret.": ".$_constER[$_ret];
        }
      else
        {
         $_ret = $_alt->addFromString('test.txt', 'testtesttest'  );
         if($_ret)
           {
            $_alt->close();
            $_retStr['success'] = "zip file made"; //<<<< this works
           }
         else
           {
            $_alt->close();
            $_retStr['error'] = "zip file not made: addFromString failed";
           }
        }
     }

// This does not else // $_POST['clsDef'] == 'true'

     {
      require_once("php/zip_archiver.php");
      $_arch = new _ZIP_ARCHIVER(getcwd(), 'dev_lab_current');
      $_input['name'] = $_POST['mkZp'];
      $_retStr = $_arch->run('newArch', '', $_input); //<<<< this code

returns ZipArchive::CREATE err 1

     }

} Although I may have some problem with my class def code.

On a completely unrelated note... Why the hell do you precede EACH and EVERYone of your variables with an underscore??? You're using $_alt, $_arch, $_input, $_retStr, etc. etc. In PHP a variable just has to start with a dollarsign, so $foo, $bar, $etc are all fine. So... why do you keep naming everything $_foo, $_bar, $_etc ?? PHP reserves $_POST, $_GET, $_REQUEST,$_COOKIE and $_SERVER as special superglobal arrays. The reason those names were chosen were because they were 'unusual' enough that they were unlikely to cause problems with people who already had variables with those names. And then here you are... using exactly those kinds of names(?!). Nowadays PHP has namespaces, and as such it's very unlikely that new superglobal PHP variables will be added to the global namespace. But still... it erks me to see this kind of coding... Like I said, on an unrelated note. Feel free to disregard.

I do that so it is easiest for me to quicly find variable references in forests of code. If you notice, I also alway concatenate variable references in strings, rather than refering to them within double quotes, or using heredoc.