Geek Answers Handbook

Manual installation of the Magento extension turns each file into a folder

I am completely puzzled by this. I packaged the extension and manually installed it on a new instance of Magento. (Both the packaging and installation machine worked Magento 1.7). The installation went smoothly, except that each installed file was turned into a folder named after the file. Every file. Has anyone come across this? Maybe this is a Magento bug?

+4
source share
7 answers

I saw this problem when I manually created a tar archive for use as a Magento Connect archive. Unfortunately, I have no solution, but here's what I understand about the problem.

While Magento Connect tgz packages are technically compressed gzip tar archives, the code that creates and extracts these archives in a non- standard * nix tar tool. Instead, Magento implemented its own packaging and unpacking tarcode for Magento Connect.

 downloader/lib/Mage/Archive/Tar.php

Unfortunately, this packaging and unpacking code did not pass reliable verification on different operating systems or tar archives created with standard * nix tools. My problem with this code was that archives created on my Mac OS system via tar would not be correctly unpacked with Magento Connect code on a Linux system.

It is difficult to track, difficult to report, difficult to reproduce, difficult to fix.

These directories are created when Magento Connect unpacks the tgz file. I'm 99% sure your directories are created using this bit of code

 #File: downloader/lib/Mage/Archive/Tar.php if (in_array($header['type'], array("0",chr(0), ''))) { if(!file_exists($dirname)) { $mkdirResult = @mkdir($dirname, 0777, true); if (false === $mkdirResult) { throw new Mage_Exception('Failed to create directory ' . $dirname); } } $this->_extractAndWriteFile($header, $currentFile); $list[] = $currentFile; } elseif ($header['type'] == '5') { if(!file_exists($dirname)) { $mkdirResult = @mkdir($currentFile, $header['mode'], true); if (false === $mkdirResult) { throw new Mage_Exception('Failed to create directory ' . $currentFile); } } $list[] = $currentFile . DS;

These are two places where Magento unpacks archives and creates a folder. For some reason, there is a certain condition for your two systems, where the data is packed or unpacked incorrectly to / from the archive file. Try not to archive the tgz file manually using the command line tool or your operating system integrated into the program without an archive. If strange things happen, then at least you know this packing code, that is the problem.

This is definitely a mistake, and while I'm reporting this, the only "solution" will not be to create your archive on your local machine (as I understand it, this is a terrible solution, but our question should not question why and all that)

+4
source

This is a bug that has been present since 1.7, due to a comparison that never evaluates to false when reading the @././LongLink . I answered this question more:

https://magento.stackexchange.com/questions/5585/long-file-names-and-magento-connect-extension-packager/45187#45187

+1
source

I found that the problem occurs when packaging the Magento extension on OS X, which is connected (modman) in the magento folders. Folder creation occurred only on Windows systems.

Perhaps this also happens?

Rico

0
source

I came across this when, for some reason, my plugin file was installed with the suffix .gz so it was plugin.tgz.gz unzip it into plugin.tgz, solving my problem

0
source

I think the problem is with the version of PHP. I faced the same problem when installing the extension on Magento 1.8.1, but found a fix by changing the _getFormatParseHeader () function in the /downloader/lib/Mage/Archive/Tar.php file.

The original function was:

 protected static final function _getFormatParseHeader() { return 'a100name/a8mode/a8uid/a8gid/a12size/a12mtime/a8checksum/a1type/a100symlink/a6magic/a2version/' . 'a32uname/a32gname/a8devmajor/a8devminor/a155prefix/a12closer'; }

I changed it to:

 protected static final function _getFormatParseHeader() { if (version_compare(phpversion(), '5.5.0', '<') === true) { return 'a100name/a8mode/a8uid/a8gid/a12size/a12mtime/a8checksum/a1type/a100symlink/a6magic/a2version/' . 'a32uname/a32gname/a8devmajor/a8devminor/a155prefix/a12closer'; } return 'Z100name/Z8mode/Z8uid/Z8gid/Z12size/Z12mtime/Z8checksum/Z1type/Z100symlink/Z6magic/Z2version/' . 'Z32uname/Z32gname/Z8devmajor/Z8devminor/Z155prefix/Z12closer'; }
0
source

Really an unpleasant mistake.

For me, this renaming of my manually packed file from *.tar.gz to *.tgz allowed it.

At least it worked on my ubuntu 15.04

Tested in Purple 1.8

0
source

it’s more likely that you are choosing the wrong path when adding content to the extension.

For me, an error occurred when I added (non-existing) files from the layout / base instead of layout / base / default.

-1
source

More articles:


All Articles