Question

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.

Answer 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.

Answer 2

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.

Answer 3

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))

友情链接