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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: your dot brother dot t at hotmail dot com
New email:
PHP Version: OS:

 

 [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-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 17:01:32 2024 UTC