2

I noticed a few days ago that a few files that belong to a certain Magento extension were in fact created as directories and not in fact the .png .css and .js files that they were supposed to be. When updating the extension there are errors as the files are unable to overwrite the existing directories. I mainly noticed this due to the icons being missing from the Magento admin panel. Although baffling, no big deal, I deleted the directories (x4) and copied the correct files from the original distribution. Problem solved.

I used find . -type d "." and also the 'empty' option to identify directories which should be files. This fixes the symptom but not the cause. There were around 10 files, mostly images but some .js and .css affected.

I've just run an update of M2e via Magento connect, 'successfully', but having noticed some missing icons/graphics in admin I checked the code and have identified 17 empty directories that should have been image files (.png and .gif).

I guess my questions are how and why is this happening? How can I stop it happening again?

I have a dedicated CentOS server running Apache. Installs are done via Filezilla FTP upload or Magento Connect, it seems most likely that it's Connect causing the problem, both extensions have been updated by Connect at least once in their lifetime.

Hoping someone can enlighten me, though not a huge problem in itself, it is a concern that critical files (rather than images) may be prone to the same problems...Anyone seen this before??

Cheers RobH

Sparko
  • 63
  • 2
  • 6

1 Answers1

2

It's a long standing problem, with multiple vectors, exacerbated by the fact the original Magento Connect team was very reluctant to engage with the outside community.

The problem is, Magento Connect package are almost, but not quite, tar archives. The packaging and unpacking of Magento Connect archives is handled by custom code in the downloader or lib folder (depending on the context)

downloader/lib/Mage/Archive/
lib/Mage/Archive/

That is -- rather than rely on the presence of command line tar, this code reimplemented tar in PHP.

This code handled 80% of use cases fine -- but over the years the Magento community has discovered (as you have) that it doesn't always work as expected. The code is internally consistent, but try packaging with one version of Magento and unpacking with a another and you'll hit weird edge cases. There are also weird edge cases when this code encounters archives made with actual tar programs in the wild -- especially tar on OS X (at least in the 10.6 era)

So, this code is sometimes bunk, and Magento Connect itself doesn't validate the uploaded extensions well enough, and may even be using some version of this code to package/repackage extensions that are uploaded by users.

I never found a great solution other than "try a different computer", and this is part of why I wrote an n98-magerun command to validate installed Connect packages.

Hope that helps!

Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • Thanks for that Alan. It does look like there is a problem with permissions on my server and it may be related to the way that I moved Magento from the old (shared) hosting onto the new (dedicated) box. This was done via a full cPanel backup on the old server and restore via WHM on the new, existing user being overwritten as an option during the restore. If I chown and chgrp for all files and dirs to my FTP/cPanel user I can't access Magento through a browser even if I set 777 permissions (!) Default group on the new server is 'nobody' (the apache user), no access with chgrp -R nobody either. – Sparko Aug 28 '15 at 08:51