5

  • I am on windows

  • I am using PHING to zip up some files

  • I have lots of things being zipped

  • Zipping works, except for ones that include a particular phing fileset in the files being zipped

  • When I debug, I can see in phing's ZIP Task that ZipArchive::close is returning false. The error string reads "permission denied". In the manual it states close() is what actually writes the file.

  • It is not temporal coupling, in other words it happens wether this one is first, last or whatever. All the other ones work. There is seemingly nothing different about this one.

Here is my build file: http://pastebin.org/84786 (good for one month)

The problem is at line 251. The zip tasks preceding and following it both work fine. In the debugger I can see about 150 files are added to the zip. I have verified all the paths to be correct in the debugger.

The build seems to work fine on linux.

When I right click the folder where the zip files are going, the read only check box is "blued out", not checked or unchecked. Wether I leave it checked or unchecked and press ok and go back into the folder's properties, the checkbox is "blue" again. Apparently this is by design (http://support.microsoft.com/kb/326549) and this does not seem like the problem since it happens only with that one file.

The other weird thing is if I go to line 252 and change the fileset to point at, for example, the files from the "importer" module right above it, it creates the zip. However the .tar.gz on line 236 the same fileset proves to work fine every time. So it only happens with the specific file set for zip tasks. The file set works fine with the tar task. In fact all the tasks under the "package" comments below it that also reference those files do not get created, but the tar.gz files do.

What gives?

Also: new observation... looks like on both Windows machines if I refresh file view fast enough I can see myzipfile.zip.tmp being built up, but myzipfile.zip never gets created.

On linux I just double checked everything is working flawlessly. Go figure.

animuson
  • 53,861
  • 28
  • 137
  • 147
Josh Ribakoff
  • 2,948
  • 3
  • 27
  • 26
  • This really sounds like a windows filesystem permission issue, try setting new permissions for entire /build/ recursively, and add rights specifically for all users (just for debugging). – kb. Feb 01 '10 at 06:20
  • As stated I already tried toggling the read only status. For both the source and build directories I went and made sure every permission was allowed for all users. It has no change on the issue. Thanks for the input – Josh Ribakoff Feb 01 '10 at 06:33
  • Did you check with a simple PHP script, eg. using fwrite(), if the PHP webuser is allowed to write in that directory? It seems so, since you can use tar.gz, but it would be a small test. – littlegreen Feb 01 '10 at 06:45
  • I put a break point write on $zip->close() (line 201 of ZipTask.php in phing). is_writable(dirname($this->zipFile->getAbsolutePath())) evaluates to true. (in case you're not following what I am doing I am asking for the parent directory of the full path the .zip file and checking if it exists and is writable. PHP says it is. – Josh Ribakoff Feb 01 '10 at 06:54
  • Ok.... two more questions, what's the exact content of `$this->zipFile->getAbsolutePath()`, eg when you echo it? And can you identify the exact statement within the PHING source code that triggers the error, eg is it line 202 of ZipTask.php and which statement is there? – littlegreen Feb 01 '10 at 07:16
  • Added new observation to end of question – Josh Ribakoff Feb 01 '10 at 07:21
  • @ littlegreen, what error? $zip->close(), which writes the zip file, is returning false. This is documented in the PHP manual. There is no error. $zipFile->getAbsolutePath() is returning the exact path name I expect. The parent path exists. – Josh Ribakoff Feb 01 '10 at 08:06
  • Let me add though, the zip class does return an *error string*, but there is no *PHP level error*. It just says "permission denied" and nothing else. I suspect it is a permission denied reading one of the input files, has to be, since it created the tmp files. – Josh Ribakoff Feb 01 '10 at 08:26
  • @Josh: What I mean is that $zip->close() generates the error, but is there some further debugging possible? eg. stepping **into** $zip->close() and seeing what generates the error (is it a file read of one of the files in your archive, a rename, a write, ...) – littlegreen Feb 01 '10 at 09:15
  • No, since it's built in the debugger sees the close() method as a black box. All operations (adding files, renaming, writing) take part during the close() method. Can't "step in" to it. Its worth mentioning this stuff all did work at some point. Now its odd that when I revert to a known working state, it no longer works. On 2 different computers too! Nothing changed (not even the php version). The result of $zip->open() is true by the way. – Josh Ribakoff Feb 01 '10 at 11:32
  • 2
    Pastebin has removed the code... – Álvaro González Mar 03 '10 at 12:39

3 Answers3

1

After your new observation, it sounds like the problem has to do with renaming the TMP file to the real ZIP file. Either there's a filename issue, or there's some kind of delayed write problem where the file's not completely done yet at the time of rename.

littlegreen
  • 7,290
  • 9
  • 45
  • 51
  • umm.. that you could try to see what happens when you put a sleep function before the ZIP file write, or see what happens when you change the filename or directory of the to-be-written-ZIP file. I really do not have eyes and ears without further debugging... – littlegreen Feb 01 '10 at 09:13
  • 1
    The ZipArchive class is a php extension (wrapper for zlib). debugbreak(); $zip->close(); That is what the code looks like. As soon as I step over that line the tmp file gets created and then removed. There is nowhere to sleep() except before or after (which is pointless, its already "sleeping" because that how GUI debugging works) – Josh Ribakoff Feb 01 '10 at 11:34
0

I haven't seen the code in question, but I was having a similar problem. It occured due to the code using forward slashes rather than back slashes. I changed the slashes and had to escape them (\\). Don't know if that helps but sometimes it is the little things that cause the biggest problems.

SethCoder
  • 66
  • 1
  • 5
0

Based on what you say about it working on Linux/Unix I would guess that you got hit by a difference in filesystem/locking semantics. In Unix files are only voluntarilly locked (other programs can still read them when they are not "locking aware"). In windows locking is enforced by the operating system meaning that you cannot read all files if they are in use by another program, and certainly not remove them (you must have had the error messages for that one). If I have to guess, you're trying to zip up a file that is locked by an active process and it fails. (As your other zip operations work I assume that writing is not a problem, and you have enough disk space/quota (and are not writing files bigger than 2GB on a FAT filesystem))

Paul de Vrieze
  • 4,888
  • 1
  • 24
  • 29