为什么 PHP 不创建这个 zip 文件（权限问题）
我在 Windows 上
我正在使用 PHING 来压缩一些文件
我有很多东西正在压缩
压缩可以工作，但正在压缩的文件中包含特定 phing 文件集的文件除外
当我调试时，我可以在 phing 的 ZIP 任务中看到 ZipArchive::close 返回 false。错误字符串显示“权限被拒绝”。在手册中，它指出 close() 是实际写入文件的内容。
这不是时间耦合，换句话说，无论这是第一个、最后一个还是其他任何一个，都会发生。所有其他的都有效。这看起来没有什么不同。
这是我的构建文件： http://pastebin.org/84786 （一个月有效）
问题是在第 251 行。它之前和之后的 zip 任务都工作正常。在调试器中，我可以看到 zip 中添加了大约 150 个文件。我已验证调试器中的所有路径都是正确的。
该构建似乎在 Linux 上运行良好。
当我右键单击 zip 文件所在的文件夹时，只读复选框被“蓝色显示”，未选中或未选中。无论我选中还是取消选中它并按“确定”并返回到文件夹的属性，该复选框都会再次变为“蓝色”。显然这是设计使然 (http://support.microsoft.com/kb/326549)这似乎不是问题，因为它只发生在那个文件上。
另一个奇怪的事情是，如果我转到第 252 行并将文件集更改为指向其上方的“导入器”模块中的文件，它会创建 zip。然而，第 236 行上的 .tar.gz 相同的文件集被证明每次都能正常工作。因此，这只发生在 zip 任务的特定文件集上。该文件集与 tar 任务配合得很好。事实上，它下面的“package”注释下的所有任务也引用了这些文件，但不会创建，但 tar.gz 文件会创建。
什么给？
另外：新的观察...看起来在两台 Windows 机器上，如果我刷新文件视图足够快，我可以看到 myzipfile.zip.tmp 正在构建，但 myzipfile.zip 永远不会被创建。
在 Linux 上，我刚刚仔细检查了一切是否正常工作。去算算吧。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据您的新观察，问题似乎与将 TMP 文件重命名为真正的 ZIP 文件有关。要么存在文件名问题，要么存在某种延迟写入问题，即文件在重命名时尚未完全完成。
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.
我没有看到有问题的代码，但我遇到了类似的问题。这是由于代码使用正斜杠而不是反斜杠而发生的。我改变了斜杠并且不得不转义它们（\\）。不知道这是否有帮助，但有时正是小事情造成了最大的问题。
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.
根据你所说的它在 Linux/Unix 上的工作情况，我猜你是因为文件系统/锁定语义的差异而受到打击。在 Unix 中，文件只是自愿锁定（其他程序在不“锁定感知”时仍然可以读取它们）。在 Windows 中，锁定是由操作系统强制执行的，这意味着如果其他程序正在使用所有文件，则您无法读取它们，当然也不能删除它们（您必须已经收到该文件的错误消息）。如果我不得不猜测，您正在尝试压缩一个被活动进程锁定的文件，但失败了。 （当您的其他 zip 操作工作时，我认为写入不是问题，并且您有足够的磁盘空间/配额（并且不会在 FAT 文件系统上写入大于 2GB 的文件））
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))