ErrorException with copy strategy

[mszterlingfsite]

Got very strange behaviour and cannot pinpoint where the problem is.
Using composer on over 10 projects and having issue only on one.

Everything works with symlink strategy (used in local environments), but problem happens when switching to copy.

To replicate I am clearing all caches

rm -rf src/.modman/*
rm -rf vendor/*

then clearing composer cache and running composer without cache

COMPOSER_CACHE_DIR=/dev/null composer install

most of the extensions are installed and then one is complaining that source file is not there.

Error is

  copy(/home/marcins/workspace/Project/src/.modman/thirdparty_magext_commercelab_new/app/code/community/CommerceLab/GreatNews/Block/Settings.php): failed to open stream: No such file or directory

I've checked src/.modman/ folder and it looks like that particular file was checked out and then deleted by magento-composer-installer.
Code is there

vendor/magento-hackathon/magento-composer-installer/src/MagentoHackathon/Composer/Magento/Deploystrategy/Copy.php 

// If file exists and force is not specified, throw exception unless FORCE is set
        if (file_exists($destPath)) {
            if ($this->isForced()) {
                unlink($destPath);
            } else {
                throw new \ErrorException("Target $dest already exists (set extra.magento-force to override)");
            }
        }

I've checked that for sure target path does not exists in the project prior running composer

Can someone point me what is going on?
If I use composer cache - it will happen with other extension on composer list. Also this extension is used on other projects and composer works as expected.

[Flyingmana]

which version of the installer are you using?
What is your composer.json?

[mszterlingfsite]

I use latest version of installer and
composer version as follows Composer version 1.0-dev (bc45d9185513575434021527d7756420e9f4b2cf) 2015-05-11 14:49:39
composer.json

{
    "minimum-stability": "dev",
    "require": {
        "xxxx/thirdparty_magext_aoe_scheduler"          : "dev-master",
        "xxxx/thirdparty_magext_ess_m2epro"             : "6.3.2",
        "xxxx/xxxx_magext_logger"                      : "0.1.1",
        "xxxx/xxxx_magext_stockimport"                 : "1.0.2",
        "xxxx/thirdparty_magext_craftyclicks_address"   : "2.4.3",
        "xxxx/thirdparty_magext_ebizmarts_magemonkey"   : "1.1.26",
        "connect20/fishpig_wordpress_integration"        : "2.4.76",
        "xxxx/xxxx_magext_banner"                      : "0.1.2",
        "xxxx/xxxx_magext_checkout"                    : "0.2.7",
        "xxxx/xxxx_magext_donations"                   : "0.1.8",
        "xxxx/xxxx_magext_newsletter"                  : "0.2.9",
        "xxxx/xxxx_magext_orderexport"                 : "1.0.11",
        "xxxx/thirdparty_magext_commercelab_new"        : "1.0.5",
        "xxxx/xxxx_magext_sagepay"                     : "0.1.2",
        "xxxx/thirdparty_magext_fooman_ordermanager"    : "2.3.0",
        "xxxx/xxxx_magext_buildrotator": "1.0.1"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "http://composer.xxxx.com"
        },
        {
            "type": "composer",
            "url": "http://packages.firegento.com"
        }
    ],
    "extra":{
        "magento-root-dir": "src/",
        "modman-root-dir": "src/.modman",
        "magento-force": "true",
        "magento-deploystrategy": "copy"
    }
}

then extensions are defined in their own composer.json as below

{
    "name": "xxxx/thirdparty_magext_commercelab_new",
    "type": "magento-module",
    "license":"proprietary",
    "description":"CommerceLab News extension",
    "authors":[
        {
            "name":"CommerceLab"
        }
    ],
    "require": {
        "magento-hackathon/magento-composer-installer": "*"
    }
}

[mszterlingfsite]

Any ideas?

[nevvermind]

Hey, @mszterlingfsite . Pretty hard to figure this one out without reproducing it.

If I use composer cache - it will happen with other extension on composer list.

Is there any extension which behaves faulty and you can share?
When is that copy happening? What do you get when installing using -vvv (debug verbosity)?

[Flyingmana]

as you make use of the modman-root-dir, you probably dont make use of the most recent 3.x release, as we dont support this anymore.

I assume the problem is created from existing symlinks, where the installer then removes one file inside this symlinked directory and then it tries to copy from there(?)
thats just a theory, I dont know enough about the modman dir feature to really analyze this :(

[mattwellss]

Everything works with symlink strategy (used in local environments), but problem happens when switching to copy.

Same thing happened to me (version constraint: ~2.1).

The solution was to delete everything from where the composer installer may put them: app, js, lib, skin, and vendor and then git checkout -- . to restore those files. After that, a composer install will have a clean canvas on which to deploy.

N.B.: If there are any non-vcs files in those dirs that won't be deployed be MCI be sure you can restore those (app/etc/local.xml and the like)

@mszterlingfsite fyi ☝️ I hope that helps.

[PascalBrouwers]

It happens because the symlinks are still there and if using extra.magento-force true then it is removing those files!
But not using extra.magento-force makes it complain about the symlinks still being there.
Only thing what works is running find . -type l -exec rm -rf {} \; before you install

[edwinljacobs]

I experienced the same problem. The issue is, as PascalBrouwers described, caused by the existence of a symlink to the vendor package. So consider the following situation: run composer install with deploy strategy "symlink", There are now symlinks to the vendor folder where the modules should be installed.

Switch to deploy strategy copy and remove the vendor folder (now the symlinks do not resolve).
If you now run composer install (with deploy strategy copy) the following happens:

see: MagentoHackathon\Composer\Magento\Deploystrategy\Copy.php line 74
Here the strategy determines if a file exists and if so remove this file. The file that is being checked is the target of the copy operation. Since this is a symlink which now resolves (because the vendor packages are back in place) the file in the vendor package gets deleted (if force is true). This is the file that gets copied (the source file). Which then results in an error when the non existent file gets copied.

Why is this the case? When running through ModuleManager doInstalls function there are various realpath calls done on either the vendor dir or the dir that should be created or linked (or whatever) in the magento codebase. I am not sure which one it is as I did not debug this properly however I am quite sure this results in the deletion of the file in the vendor dir. How to avoid this? Make sure when switching to deploy strategy copy that no symlinks which resulted from deploy strategy symlink are present in the project. Clean it all up.

Somebody accedentally commited the symlink in Git (in my case) and this caused the issue. I did spend some time to figure out why this happened, therefor this update. It problably can be fixed by avoiding the use of realpath.