几天前我注意到，属于某个 Magento 扩展的一些文件实际上是作为目录创建的，而不是它们应该是的 .png .css 和 .js 文件。更新扩展时会出现错误，因为文件无法覆盖现有目录。我注意到这一点主要是因为 Magento 管理面板中缺少图标。虽然令人困惑，但没什么大不了的，我删除了目录(x4)并从原始发行版中复制了正确的文件。问题解决了。
我使用了 find 。 -type d "."以及“空”选项来标识应该是文件的目录。这解决了症状，但没有解决原因。大约有 10 个文件，主要是图像，但一些 .js 和 .css 受到影响。
我刚刚通过 Magento 连接“成功”运行了 M2e 更新，但注意到管理中缺少一些图标/图形，我检查了代码并发现了 17 个本应是图像文件的空目录(.png 和.gif)。
我想我的问题是这是如何以及为什么会发生？我怎样才能阻止它再次发生？
我有一个运行 Apache 的专用 CentOS 服务器。安装是通过 Filezilla FTP 上传或 Magento Connect 完成的，看起来很可能是 Connect 导致了问题，这两个扩展在其生命周期中至少已由 Connect 更新过一次。
希望有人能启发我，虽然本身不是一个大问题，但令人担心的是关键文件(而不是图像)可能容易出现同样的问题......以前有人见过这个吗？？
干杯 罗布H
最佳答案
这是一个长期存在的问题，有多个向量，而最初的 Magento Connect 团队非常不愿意与外部社区接触，这一事实加剧了这一问题。
问题是，Magento Connect 包几乎是 tar 存档，但不完全是。 Magento Connect 文件的打包和解包由 downloader 或 lib 文件夹中的自定义代码处理(取决于上下文)
downloader/lib/Mage/Archive/
lib/Mage/Archive/
也就是说，这段代码在 PHP 中重新实现了 tar，而不是依赖于命令行 tar。
这段代码可以很好地处理 80% 的用例——但是多年来，Magento 社区发现(正如您所发现的那样)它并不总是按预期工作。代码在内部是一致的，但是尝试使用一个版本的 Magento 打包并使用另一个版本解包，您会遇到奇怪的边缘情况。当此代码遇到使用实际 tar 程序在野外生成的存档时，也会出现奇怪的边缘情况 - 尤其是 OS X 上的 tar (至少在 10.6 时代)
因此，这段代码有时是废话，Magento Connect 本身并不能很好地验证上传的扩展，甚至可能使用此代码的某些版本来打包/重新打包用户上传的扩展。
除了“尝试不同的计算机”之外，我从未找到过更好的解决方案，这就是我向 validate installed Connect packages 编写 n98-magerun 命令的部分原因。 .
希望有帮助!
关于magento - CentOs Magento 文件创建为目录？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32227126/