Edit report at http://bugs.php.net/bug.php?id=54128&edit=1
ID: 54128 User updated by: vavra at 602 dot cz Reported by: vavra at 602 dot cz Summary: ZIP_ER_OPEN when ZipArchive::open() on temp file Status: Assigned Type: Bug Package: Zip Related Operating System: Windows 2003 PHP Version: 5.2.17 Assigned To: pajoye Block user comment: N Private report: N New Comment: The right permission for temp folder are default right permission for Windows Server systems. Microsoft probably has a security reason for not allowing IUSR_XXXX user for listing a temp dir. Yes I can fix it by changing permissions or not using Windows Temp dir. I do not fordid you not testing file existence. I offer not do it by stat function ;-) Previous Comments: ------------------------------------------------------------------------ [2011-03-02 10:50:22] [email protected] The bug is a side effect of the permission issue. But we have (I repeat: we have) to do the existence check for the reason I explained earlier. I will see what can be done to still make it works but you better have to fix your perms instead. ------------------------------------------------------------------------ [2011-03-02 10:44:59] vavra at 602 dot cz The function _zip_file_exists() is used only once in zip_open() after creating new or reading for open. The usage is not so universal. There is no need for testing of existence of file for which we have no read access. It's used in zip_open() and zip_open() reads or writes to a file. So you are testing existence of file and you have to have at least a read permission. So if you reimplement _zip_file_exists() with fopen you will not lose anything and users of ZipArchive will quite earn. Case where implementation of some file_exists() via fopen cannot be used is for example implementaion of tempnam - function which tries to generate unique file and can randomly generate some filename. There is a probability that filename exists and you have no read right. Again in zip_open() such universal behaviour of file_exists() function isn't required. So I thing you can reimplement it and you can spare a lot of time of ZipArchive users. See my test case: file_get_contents succeeded but ZipArchive:open not. Isn't it weird? ------------------------------------------------------------------------ [2011-03-02 09:56:17] [email protected] zip_file_exists is about testing the existence of a file so stat usage is perfectly valid in this case. We also have to test if the file exists, because of the options available on zip_open (create, overwrite, etc.). ------------------------------------------------------------------------ [2011-03-02 08:47:16] vavra at 602 dot cz Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_XXXX has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded. So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function. ------------------------------------------------------------------------ [2011-03-01 15:55:09] [email protected] I assume this is expected bahvior. At least on UNIX/Linux systems stat is defined as The stat() function obtains information about the file pointed to by path. Read, write, or execute permission of the named file is not required, but all directories listed in the path name leading to the file must be searchable. I assume it is similar on Windows. If the zip extension is accessing the temp dir this should probably be documented. Assigning to Pierre who knows zip and windows better :-) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54128 -- Edit this bug report at http://bugs.php.net/bug.php?id=54128&edit=1
