php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #68621 ZipArchive::open(): support stream wrappers
Submitted: 2014-12-18 13:56 UTC Modified: 2015-06-04 13:22 UTC
Votes:5
Avg. Score:3.6 ± 1.5
Reproduced:5 of 5 (100.0%)
Same Version:3 (60.0%)
Same OS:2 (40.0%)
From: your dot brother dot t at hotmail dot com Assigned:
Status: Open Package: Zip Related
PHP Version: all OS: Cross OS
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
47 - 5 = ?
Subscribe to this entry?

 
 [2014-12-18 13:56 UTC] your dot brother dot t at hotmail dot com 
Description:
------------
---
From manual page: http://www.php.net/ziparchive.open
---
The ZipArchive::open treats the filename not as defined per php manual on valid file wrappers. It appends the filename to the base url. Hence, creating/manipulating a zip file in memory space would be impossible.

Test script:
---------------
$zip = new \ZipArchive();
if (!($err = $zip->open("php://memory", \ZipArchive::CREATE)))
{
	die(var_dump($err));
}
$zip->addFromString("test.txt", "sample text");
die(var_dump($zip));

Expected result:
----------------
object(ZipArchive)[206]
  public 'status' => int 0
  public 'statusSys' => int 0
  public 'numFiles' => int 1
  public 'filename' => string 'php://memory' (length=54)
  public 'comment' => string '' (length=0)

Actual result:
--------------
object(ZipArchive)[206]
  public 'status' => int 0
  public 'statusSys' => int 0
  public 'numFiles' => int 1
  public 'filename' => string 'D:\servers\www\html\Laravel\sandbox\public\php:\memory' (length=54)
  public 'comment' => string '' (length=0)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-03-07 09:06 UTC] neeke@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: neeke
 [2015-03-07 09:09 UTC] neeke@php.net
-PHP Version: 5.6.3 +PHP Version: all
 [2015-04-06 13:30 UTC] neeke@php.net
-Assigned To: neeke +Assigned To:
 [2015-04-06 13:33 UTC] neeke@php.net
-Assigned To: +Assigned To: neeke
 [2015-04-06 13:33 UTC] neeke@php.net 
https://github.com/php/php-src/pull/1159
 [2015-04-16 13:11 UTC] cmb@php.net
-Package: zip +Package: Zip Related
 [2015-04-16 13:11 UTC] cmb@php.net 
What's the status here? It seems the PR has been closed on 9 Mar
without having been merged into upstream.
 [2015-06-04 13:22 UTC] cmb@php.net
-Summary: Filename appends the base url. +Summary: ZipArchive::open(): support stream wrappers -Status: Assigned +Status: Open -Type: Bug +Type: Feature/Change Request
 [2015-06-04 13:22 UTC] cmb@php.net 
I had a closer look at the issue. PR #1159 caters only to the very
special use case of php://memory, but not to general stream
wrappers. However, it doesn't make sense to create a zip archive
in php://memory, because the file would only be created there
after calling ZipArchive::close() (normal behavior of ZipArchive),
but then the created archive couldn't be accessed anymore. It
might make sense to allow for other stream wrappers such as
ftp://, though.

Anyhow, ZipArchive::open() is not supposed to accept any stream
wrapper URLs, but only real file paths. Its documentation doesn't
tell otherwise, and neither does the man page on "Supported
Protocols and Wrappers"[1]:

| PHP comes with many built-in wrappers for various URL-style
| protocols for use with the filesystem functions [...]

However, ZipArchive::open() is not a filesystem function for that
matter.

So, actually, this is not a bug, not even a documentation bug in
the strict sense. Therefore I'm changing to feature request.

[1] <http://php.net/manual/en/wrappers.php>
 [2015-06-04 13:22 UTC] cmb@php.net
-Assigned To: neeke +Assigned To:
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 16:00:01 2025 UTC