10000 Failed to extract package with warning: stripped absolute path spec from · Issue #10099 · composer/composer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Failed to extract package with warning: stripped absolute path spec from #10099

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jnaklaas opened this issue Sep 13, 2021 · 10 comments
Closed
Labels

Comments

@jnaklaas
Copy link
jnaklaas commented Sep 13, 2021

When requiring my latest composer packages (built with satis, see this issue), extracting fails. The package is unzipped, but all files are inside a nested subdirectory, instead of in the root of the package directory:
vendor/mypackage/var/folders/21/gnrfrmtx7z72qv4j9cc7psvc0000gn/T/composer_archive613f6e6d68385/

So the package is not properly installed and not available in the project. When I require an older version of the package, it unzips and installs as expected: composer require myvendor/mypackage:1.1.6.

My composer.json:

{
  "name": "test/test",
  "type": "project",
  "repositories": [
    {
      "type": "composer",
      "url": "https://packages.myvendor.tld"
    }
  ],
  "require": {
    "php": ">=7.1",
    "myvendor/mypackage": "^1.1"
  }
}

Output of composer diagnose:

Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 2.1-dev+4bcd860b6574fd71553019296965613cbaf95161
PHP version: 7.4.10
PHP binary path: /usr/local/Cellar/php/7.4.10/bin/php
OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020
cURL version: 7.74.0 libz 1.2.11 ssl (SecureTransport) Ope

When I run this command:

composer install
# or
composer require myvendor/mypackage

I get the following output:

No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
  - Locking jjgrainger/posttypes (2.1)
  - Locking myvendor/mypackage (1.1.10)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Installing jjgrainger/posttypes (2.1): Extracting archive
  - Installing myvendor/mypackage (1.1.10): Extracting archive
 0/2 [>---------------------------]   0%    Failed to extract myvendor/mypackage: (1) '/usr/bin/unzip' -qq '/Users/path/vendor/composer/tmp-ed1e61d2ce725728386eea2f712ebfce.zip' -d '/Users/path/vendor/composer/e40138b7'

warning:  stripped absolute path spec from /private/var/folders/21/gnrfrmtx7z72qv4j9cc7psvc0000gn/T/composer_archive613f6e6d68385/composer.lock
warning:  stripped absolute path spec from /private/var/folders/21/gnrfrmtx7z72qv4j9cc7psvc0000gn/T/composer_archive613f6e6d68385/mypackage.php
# above warning repeats for every single file in the package

    The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems)
    Unzip with unzip command failed, falling back to ZipArchive class
Generating autoload files

And I expected something similar to this to happen: this is the output from a downgrade to a previous version of my package, which still works:

./composer.json has been updated
Running composer update myvendor/mypackage
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
  - Downgrading myvendor/mypackage (1.1.10 => 1.1.6)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Downloading myvendor/mypackage (1.1.6)
  - Downgrading myvendor/mypackage (1.1.10 => 1.1.6): Extracting archive
Generating autoload files
@Seldaek
Copy link
Member
Seldaek commented Sep 13, 2021

The warnings:

warning: stripped absolute path spec from /private/var/folders/21/gnrfrmtx7z72qv4j9cc7psvc0000gn/T/composer_archive613f6e6d68385/composer.lock
warning: stripped absolute path spec from /private/var/folders/21/gnrfrmtx7z72qv4j9cc7psvc0000gn/T/composer_archive613f6e6d68385/mypackage.php

This seems to indicate the archive contains the full absolute path from when it was created. So it may be a bug in the archive command, or it may be a bug in satis. I have no idea, but it'd be great if you can dig further and try to figure it out as this isn't really code I am familiar with and I don't have a ton of time atm to dig into this myself.

@stof
Copy link
Contributor
stof commented Sep 14, 2021

@Seldaek Satis uses the archiver of Composer to build th 8000 e archive, so the bug is more likely in Composer than in Satis.

@jnaklaas
Copy link
Author

I've been looking at the archive command like a cow looking at a train. I'm not going to figure out what's going wrong there even if I wanted to.

@mvorisek
Copy link
Contributor
mvorisek commented Sep 20, 2021

I can confirm this bug, see https://github.com/atk4/core/runs/3651286339?check_suite_focus=true

CI is failing randomly in about 1 of 100 runs.

     Failed to extract atk4/data: (1) '/usr/bin/unzip' -qq '/__w/core/core/vendor/composer/tmp-fb6ab8c116eeb3580199ebac35df7953' -d '/__w/core/core/vendor/composer/bff374b9'

unzip: short read

    The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems)
    Unzip with unzip command failed, falling back to ZipArchive class
    Install of atk4/data failed

Error: '/__w/core/core/vendor/composer/tmp-fb6ab8c116eeb3580199ebac35df7953' is not a zip archive.
                                                                                               
  [UnexpectedValueException]                                                                   
  '/__w/core/core/vendor/composer/tmp-fb6ab8c116eeb3580199ebac35df7953' is not a zip archive.  
                                                                                               

@Seldaek
Copy link
Member
Seldaek commented Oct 14, 2021

@jnaklaas can you try my fix suggestion in #10126 (comment) ?

@ballet-mecanique
Copy link

@Seldaek I've had the same issue as @mvorisek and tried the fix in suggesion #10126 but it didn't help. I'm also still getting 'stripped absolute path spec' warnings when running composer require on a package hosted via Satis, and the package can't auto-register correctly as a result.

@introwit
Copy link

@Seldaek @ballet-mecanique @jnaklaas I solved this. The error happens when you build satis locally and deploy that. I deleted the public folder (my output-dir) that was created after I was testing the build locally, and pushed the changes. I have post-deployment hook setup that runs php bin/satis build which built the output-dir on the live server. Tried installing the package again and everything worked flawlessly. Thank you for Satis @Seldaek and team ❤️

@mvorisek
Copy link
Contributor

the issue I reported in #10099 (comment) was using regular dist zip files from packagist.org/GH, but I haven't seen such issue for a long time, thus it was probably fixed in a composer or somewhere else, I am unsubscribing myself from this issue and it can be probably even closed

@Seldaek Seldaek closed this as completed Jun 7, 2022
@andrewgosselin
Copy link
andrewgosselin commented Aug 2, 2022 8FBD

I just recently had this issue only using MacOS, the way I fixed it was just building it on my server instead which was running Ubuntu. I believe this to be an issue specifically when building and uploading from MacOS, the command I ran to deploy this was ./bin/satis build -n -vvv satis.json web/ && (cd web && aws s3 sync --delete . s3://satis/). Hopefully this helps someone that stumbles upon this issue.

@jasonmccreary
Copy link
Contributor

I am having this issue when building locally on MacOS and deploying to a static satis server. I have a build process to create a private package, so ideally I wouldn't need to recreate this process on the live server to then generate the archives.

I'm wondering if this issue could be revisited with a focus on building locally on MacOS or someone on the core team could point me in the right direction to help try some fixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants
0