Use a different temp directory each time for downloading remote patches

[James-Oakley]

Verification

• I have updated Composer to the most recent stable release (composer self-update)
• I have updated Composer Patches to the most recent stable release (composer update cweagans/composer-patches)
• I am using one of the supported PHP versions (8.0+)
• I have searched existing issues and discussions for my idea.

Is your feature request related to a problem?

I'm enjoying exploring the 2.0.0 version. Thank you.

One snag I hit was when I tried to run composer pd on the second project on the same server. I got an error that composer couldn’t create a file in /tmp/composer-patches. This directory had been created when I applied patches on the first project I'd worked on. It was therefore owned by the owner for that first project's directory, and had permissions 644. My second project, running on a different Linux account, therefore could not create the directory (it already existed) and so could not write to it.

I got around this by creating a custom .user.ini file for my php cli to pick up, that contained sys_temp_dir=/home/{username}/tmp

Describe your proposed solution(s)

Instead of attempting to write patches into /tmp/composer-patches, use a folder like /tmp/composer-patches-`date +%s` . It would need cleaning up afterwards.

Describe alternatives

In the extra > composer-patches section within composer.json, allow a new entry: "tmp_dir": "{directory}"

This may not work when composer.json is checked into version control. If the project's temporary patching directory was hard-wired into composer.json, the same directory would be used in any environment. That could cause problems, assuming there was no way to resolve ~ within php, because an absolute path /home/user1/tmp would not work if someone is developing a project in /home/user2.

Additional context

No response

[github-actions]

👋 Thanks for the idea! Please remember that this is an open source project - feature requests may or may not be implemented, and if they are, the timeline is unknown. If you need a guaranteed implementation or timeline, sponsorships are welcome!

[cweagans]

My second project, running on a different Linux account, therefore could not create the directory (it already existed) and so could not write to it.

You have separate accounts for different projects you're working on? That sounds like a lot of work lol.

Instead of attempting to write patches into /tmp/composer-patches, use a folder like /tmp/composer-patches-date +%s . It would need cleaning up afterwards.

The expected behavior is that it's using the Composer cache directory, and there really shouldn't be collisions within that directory either (given that each patch is named with its sha256 hash -- if there are identical patches in different projects, you'll just re-use the one you've already downloaded). If you're running with --no-cache for some reason, it'll use the system temp dir (logic is here). If you want the patch downloads to end up in a different location, you can set the cache-dir option in your composer.json. I suspect that there is probably more to your setup than you've described though.

[James-Oakley]

Thanks for replying Cameron.

My setup isn't that complex. I work on multiple websites. Each of those has a development copy running on a development server. They'll have domains like dev.site1, dev.site2 and so on. Each of those has its own Linux account on the server, so that public_html loads the site in question.

I'm not knowingly running composer with --no-cache.

For whatever reason, it didn't use ~/.cache/composer, but /tmp/composer-patches. That directory didn't exist for dev.site1, so the directory was created, therefore owned by devsite1:devsite1, permissions 755. When I upgraded dev.site2 to 2.0.0, it saw that /tmp/composer-patches already existed, but it couldn't write to it.

I could create a group for all my dev accounts on that server, chmod g+w /tmp/composer-patches, and add the accounts to the group. Or I can override sys_temp_dir for PHP cli in those accounts.

Maybe my setup is atypical (?), but I thought it worth raising here in case there's anything others too might struggle with.

[cweagans]

Are you running this in a container, by chance? When I ran docker run composer:latest config --global home, I got /tmp. When I docker run -it ubuntu:22.04, then apt install php, then install Composer and run composer config --global home, I get /root/.composer.

This might be a simple matter of setting the COMPOSER_HOME environment var to $HOME/.composer. (I was wrong about the path, btw: the cache dir is ~/.composer/cache -- that's the composer default)

[James-Oakley]

Thanks.

Not running in a container; this is a dedicated server.

I've tried setting the environment variable.

$ echo $COMPOSER_HOME
/home/devsite1/.composer

I then ran composer prp, which worked.

$ ls /tmp/composer-patches/ -l
total 228
drwxr-xr-x   2 devsite1 devsite1      6 Nov 15 11:48 ./
drwxrwxrwt. 81 root        root        552960 Nov 15 11:48 ../

$ ls ~/.composer/cache/patches/ -l
total 8
drwxr-xr-x 2 devsite1 devsite1  162 Nov 15 11:48 ./
drwxr-xr-x 4 devsite1 devsite1   51 Nov 15 11:48 ../
-rw-r--r-- 1 devsite1 devsite1  992 Nov 15 11:48 058ad29d77c25c44b8984b705e28af4bd807cdc22e9238718a5a91db4487407c.patch
-rw-r--r-- 1 devsite1 devsite1 2164 Nov 15 11:48 09e6faa26363e48c745508aa2f6a30f5fbb1688f13a29da6618d344900891eaf.patch

I then ran composer prp again, but this time ran chmod -w /tmp/composer-patches/ first, and all was fine.

But it turned out that was because the patches were cached so did not need to be downloaded. If it has to download the patches, it is saving them in /tmp/composer-patches (or, more accurately, a directory named composer-patches within sys_temp_dir) first, before moving them to composer's cache directory.

$ chmod -w /tmp/composer-patches/
$ rm ~/.composer/cache/patches/ -rf
$ composer prp
{output fluff snipped}
Unhandled promise rejection with Composer\Downloader\TransportException: The "https://www.drupal.org/files/issues/2025-11-09/update_module_stuck-2920285-63.patch" file could not be written to /tmp/composer-patches/69186934cb6b1.patch: Failed to open stream: Permission denied in phar:///usr/local/bin/composer/src/Composer/Util/Http/CurlDownloader.php:190
Stack trace:
#0 phar:///usr/local/bin/composer/src/Composer/Util/Http/CurlDownloader.php(132): Composer\Util\Http\CurlDownloader->initDownload()
#1 phar:///usr/local/bin/composer/src/Composer/Util/HttpDownloader.php(339): Composer\Util\Http\CurlDownloader->download()
#2 phar:///usr/local/bin/composer/src/Composer/Util/HttpDownloader.php(299): Composer\Util\HttpDownloader->startJob()
#3 phar:///usr/local/bin/composer/src/Composer/Util/HttpDownloader.php(156): Composer\Util\HttpDownloader->addJob()
#4 /home/devsite1/composer-root/vendor/cweagans/composer-patches/src/Downloader/ComposerDownloader.php(32): Composer\Util\HttpDownloader->copy()
#5 /home/devsite1/composer-root/vendor/cweagans/composer-patches/src/Downloader.php(74): cweagans\Composer\Downloader\ComposerDownloader->download()
#6 /home/devsite1/composer-root/vendor/cweagans/composer-patches/src/Plugin/Patches.php(247): cweagans\Composer\Downloader->downloadPatch()
#7 /home/devsite1/composer-root/vendor/cweagans/composer-patches/src/Plugin/Patches.php(351): cweagans\Composer\Plugin\Patches->download()
#8 phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php(220): cweagans\Composer\Plugin\Patches->patchPackage()
#9 phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php(150): Composer\EventDispatcher\EventDispatcher->doDispatch()
#10 phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php(399): Composer\EventDispatcher\EventDispatcher->dispatchPackageEvent()
#11 phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php(414): Composer\Installer\InstallationManager::Composer\Installer\{closure}()
#12 phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php(322): Composer\Installer\InstallationManager->executeBatch()
#13 phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php(221): Composer\Installer\InstallationManager->downloadAndExecuteBatch()
#14 phar:///usr/local/bin/composer/src/Composer/Installer.php(839): Composer\Installer\InstallationManager->execute()
#15 phar:///usr/local/bin/composer/src/Composer/Installer.php(300): Composer\Installer->doInstall()
#16 phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php(147): Composer\Installer->run()
#17 phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php(298): Composer\Command\InstallCommand->execute()
#18 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php(1040): Symfony\Component\Console\Command\Command->run()
#19 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php(301): Symfony\Component\Console\Application->doRunCommand()
#20 phar:///usr/local/bin/composer/src/Composer/Console/Application.php(396): Symfony\Component\Console\Application->doRun()
#21 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php(171): Composer\Console\Application->doRun()
#22 phar:///usr/local/bin/composer/src/Composer/Console/Application.php(136): Symfony\Component\Console\Application->run()
#23 /home/devsite1/composer-root/vendor/cweagans/composer-patches/src/Command/RepatchCommand.php(60): Composer\Console\Application->run()
#24 phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php(298): cweagans\Composer\Command\RepatchCommand->execute()
#25 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php(1040): Symfony\Component\Console\Command\Command->run()
#26 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php(301): Symfony\Component\Console\Application->doRunCommand()
#27 phar:///usr/local/bin/composer/src/Composer/Console/Application.php(396): Symfony\Component\Console\Application->doRun()
#28 phar:///usr/local/bin/composer/vendor/symfony/console/Application.php(171): Composer\Console\Application->doRun()
#29 phar:///usr/local/bin/composer/src/Composer/Console/Application.php(136): Symfony\Component\Console\Application->run()
#30 phar:///usr/local/bin/composer/bin/composer(93): Composer\Console\Application->run()
#31 /usr/local/bin/composer(29): require('...')
#32 {main}

In CurlDownloader.php line 190:
                                                                                                                                                               
  The "https://www.drupal.org/files/issues/2025-11-09/update_module_stuck-2920285-63.patch" file could not be written to /tmp/composer-patches/69186934cb6b1.  
  patch: Failed to open stream: Permission denied 

[bluec]

Thanks for replying Cameron.

My setup isn't that complex. I work on multiple websites. Each of those has a development copy running on a development server. They'll have domains like dev.site1, dev.site2 and so on. Each of those has its own Linux account on the server, so that public_html loads the site in question.

I'm not knowingly running composer with --no-cache.

For whatever reason, it didn't use ~/.cache/composer, but /tmp/composer-patches. That directory didn't exist for dev.site1, so the directory was created, therefore owned by devsite1:devsite1, permissions 755. When I upgraded dev.site2 to 2.0.0, it saw that /tmp/composer-patches already existed, but it couldn't write to it.

I could create a group for all my dev accounts on that server, chmod g+w /tmp/composer-patches, and add the accounts to the group. Or I can override sys_temp_dir for PHP cli in those accounts.

Maybe my setup is atypical (?), but I thought it worth raising here in case there's anything others too might struggle with.

I have the exact same problem and just chipping in to say this is not atypical. It is basic security good practice to have isolation of projects under different linux users.

The proposed PR #680 looks like a good solution to me, its a shame it hasn't been merged and released.

[bluec]

@James-Oakley as a quick fix you can set the sys_temp_dir at runtime, so something like this in your deployment script

COMPOSER_TMP_DIR="$HOME/.composer-tmp"
mkdir -p "$COMPOSER_TMP_DIR"
php -d sys_temp_dir="$COMPOSER_TMP_DIR" composer install

[James-Oakley]

@James-Oakley as a quick fix you can set the sys_temp_dir at runtime

Thanks, I'm doing something very similar to that. I have a cli .user.ini file for PHP that sets sys_temp_dir=/home/accountname/tmp.

So I have a work-around. As you say, it would be good to get the PR merged and released.