Has anyone noticed that Magento Connect packager and installer (mage script) cannot handle long file paths inside the tgz archive? I've got a file app/code/community/Eepohs/EestiPostLt/Model/System/Backend/Config/Source/Sending/Additionalservice.php inside an installer package. When I install this package by using mage script it creates directory named app/code/community/Eepohs/EestiPostLt/Model/System/Backend/Config/Source/Sending/Additionalservice.p

After a long investigation I discovered that the unarchiver Mage_Archive_Tar does not handle paths longer than 100 characters correctly. Has anyone noticed that, too? Is there any quick fix to that?

  • 1
    What are you using to create the tar package? I've not done a ton of packaging, and have never run into it, but Magento appears to correctly handle the packaging of tar files where long file names are present. At least when it's creating the package. For reference, see Mage_Archive_Tar::_composeHeader, where it's building both the long and packed headers needed for this. — Maybe try unpacking it with another tool to see if it's packed correctly?
    – davidalger
    Jul 10, 2013 at 13:58
  • 1
    I didn't have this issue, but some people had the issue with one of the extension I created. One of the guys said this: 'I think the path of ****.php is too long to be able to "double" extract in cache memory (gunzip first then untar), depending on some settings in OS'. If it's an OS problem then I don't think you can do anything about it. To verify this, try an other OS.
    – Marius
    Jul 10, 2013 at 14:10
  • Hi, we're packaging it with the same Magento (Connect->Package Extensions). I'm working on OSX. Good idea to try it on a Linux. When unpackaged with OS tar then it's correct. The problem lies in _composeHeader or near it, I'm quite sure.
    – Sven
    Jul 11, 2013 at 8:02
  • In my previous comment I was talking about the packer/unpacker used by Magento. At least that's what some users reported.
    – Marius
    Jul 12, 2013 at 8:24
  • 1
    If it's correctly unpackaged with the OS tar, then it would appear that the bug lies in reading / decoding the headers. I.e. _composeHeader is doing it right (or the OS wouldn't be able to unpack it correctly) but interpreting the headers for unpacking isn't supporting the long headers properly.
    – davidalger
    Jul 13, 2013 at 15:54

2 Answers 2


As B00MER mentioned this is tangentially related to the differences between FreeBSD tar and GNU tar.

Magento correctly uses the @././LongLink functionally of GNU Tar when packaging the extension but there has a bug in the extraction side since version 1.7.

The offending line is in downloader/lib/Mage/Archive/Tar.php b/downloader/lib/Mage/Archive/Tar.php

replace the following line

if (!($header['name'] == '././@LongLink' && $header['type'] == 'L')) {


if (!(trim($header['name']) == '././@LongLink' && $header['type'] == 'L')) {

which will fix the issue of the if statement never failing and the long header never being read.

You can find a full write up here along with a diff/patch file: Long File Names Magento Connect Bug


This is an issue with POSIX implementation differences with FreeBSD tar and GNU tar.

Magento_Archive_Tar tries to work around this but whatever package you are using to extract is only reading the old "100" character limit second header and not looking for the full path/filename in the first header.

  • 1
    What @BOOMER said. The only thing I'd add is I don't think the problem's fully understood, and it's been hard to track down given the permutations of "tar-ed with Magento X.X on OS Y version X.X". My quick fix has been to package files on a linux VPS I have lying around with a command line script I ginned up. github.com/astorm/MagentoTarToConnect Jul 30, 2013 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.