views:

539

answers:

4
  • 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.

A: 

Josh, do u mean the error will occurred only on windows? If its, there may be issue on permission settings. Vista has some bull-shit issue in permission settings. I tried to change my location in several times in several ways. but it was not changed. sometimes can access that folder to change. But not every time. However, cn u check that on another machine?

Sadee
-1 for asking for what is already said, for "bull-shit issue", and for "cn u".
ax
I checked on another Vista machine, problem also happens there.
Josh Ribakoff
+2 for Vista-bashing, -1 for style. Some inspiration: http://xkcd.com/528
littlegreen
+1  A: 

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
and this implies/entails?
Josh Ribakoff
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
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
A: 

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
A: 

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