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

go to bug id or search bugs for

Bug #45156 2 ZIP archives created when creating archive in folder wwwroot
Submitted: 2008-06-03 09:58 UTC Modified: 2008-06-03 13:43 UTC
From: harlequin2 at gmx dot de Assigned: pajoye (profile)
Status: Closed Package: Zip Related
PHP Version: 5.2.6 OS: Windows 2003 SP2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: harlequin2 at gmx dot de
New email:
PHP Version: OS:

 

 [2008-06-03 09:58 UTC] harlequin2 at gmx dot de 
Description:
------------
If I create a ZipArchive in the folder "C:\Inetpub\wwwroot", then two zip files are created with the names "temp.zip.a11860" and "temp.zip.b11860". Renaming the files to "temp.zip" and opening it shows that both files contain the same files, so it's not something like a splitted archive.
If I change $filename (i.e. "C:/Inetpub/temp.zip" or anything else), then only one file is created. I checked if it has something to do with dos' maximum filename length, but that was not the case. The effect only occurres when the file is created within the folder "wwwroot", subfolders included.

Reproduce code:
---------------
$filename = "C:/Inetpub/wwwroot/temp.zip";
// I also tried ZIPARCHIVE::OVERWRITE
if ($zip->open($filename, ZIPARCHIVE::CREATE)!== true){
    $zip->addFile("test.xls", "test.xls");
$zip->close();

Expected result:
----------------
One ZipArchive with the name "temp.zip" created

Actual result:
--------------
Two ZipArchives with the names "temp.zip.a11860" and "temp.zip.b11860" created

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-03 10:48 UTC] pajoye@php.net 
> zip files are created with the names "temp.zip.a11860"

One temp file is created until the archive is closed (finished).

Do you see them while creating the archive or even after you called the close method?

If you see them after the close call, please check the return value of the close call as well as other methods.
 [2008-06-03 12:00 UTC] harlequin2 at gmx dot de 
I see the two created files after I have called $zip->close() and after the script has finished running. A call to $zip->status returns 0, $zip->numFiles is showing 1 item in the file.
There are no previous methods executed.
 [2008-06-03 12:23 UTC] pajoye@php.net 
Can you try:

error_reporting(E_AL));
$filename = "C:/Inetpub/wwwroot/test.txt";
touch($filename);
unlink($filename);

(be sure to have display_errors to On).

The 2nd test is to run the same script using CLI. I don't have access to windows 2k3 right now, but I can test that too later this week.
 [2008-06-03 13:33 UTC] harlequin2 at gmx dot de 
I tried:

error_reporting(E_ALL);
$filename = "C:\\Inetpub\\wwwroot\\temp.zip";
touch($filename);
unlink($filename);

and the touch()ing worked, the timestamp was modified. The unlink() returned an "Access denied" message, although I added "Everyone" to the list of allowed users with "Full control".

Good idea to test from CLI:
When the script is executed through CLI (under the local user context), the file is created correctly, only one file remains. The unlink() command also works without problems.

Seems to be related to Windows 2K3 security policies, but it's still strange to receive the same result code (result code 0) from both web and cli call.
 [2008-06-03 13:43 UTC] harlequin2 at gmx dot de 
After removing all groups (with the exception of "Everyone") and leaving that one with all privileges, both creating a zip file and deleting files from the folder work.

In my eyes the bug could be closed, but I still wonder if a return code other than 0 could be thrown if renaming the zipfile to the desired zipfile name fails.

Thanks for your support!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 05:01:27 2025 UTC