Permission bits are lost in archives

[doalex]

It seems that files in archived packages are loosing permission bits on Linux, in my case the executable flag which was set for a php file.
I tried both zip and tar archive formats.

    "archive": {
        "directory": "dist",
        "skip-dev": true,
        "format": "tar"
    }

The permission bits are preserved if I use the --prefer-source flag while installing the package.

I also tried to create an archive using composer archive which has the same problem.

Is there a way to preserve the permission bits in archives on Linux?
Thanks

[alcohol]

Afaik composer/composer uses Phar to handle tar archives. It could be that these indeed do not support permissions.

[oligriffiths]

@doalex Do you do --prefer-source on the host or on the satis server?

[doalex]

@oligriffiths on the host while installing packages, but if you always use --prefer-source you don't really need the archive feature.

[oligriffiths]

That doesn't work for us as we commit our vendor dir and the .git directories cause problems that way.

On 13 May 2016, at 03:35, Alex notifications@github.com wrote:

@oligriffiths on the host while installing packages, but if you always use --prefer-source you don't really need the archive feature.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[kevindierkx]

@oligriffiths Why not exclude them in your .gitignore? Something like vendor/**/.git/

[oligriffiths]

I should have explained further.

We do currently do that, however it causes problems with composer when updating dependencies as it relies on the git directory being there to do a subsequent pull to update the repo.

On 13 May 2016, at 17:12, Kevin Dierkx notifications@github.com wrote:

@oligriffiths Why not exclude them in your .gitignore? Something like vendor/**/.git/

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[andrerom]

@alcohol I'm running into this issue so wondering if it should be kept open, or that we reopen;

• tried on 1.x + composer 1.8-dev
• tried using prefer dist or source, verified that execution bit is kept on download either way and that the issue is archive stage.
• I have tried both tar and zip format, but did not see a difference.
• I tried to patch ZipArchive to call setExternalAttributesName both no perceived difference: andrerom/composer@8ad090a

Any possible setups where this is expected to work?

I detected this on our server running linux, and the steps above to try different things where done locally on mac with php 7 + zip extension.

[alcohol]

The problem stems from environment. You need to have a good tar/zip handler installed.

[andrerom]

So in regards to these?

zip

Zip => enabled
Zip version => 1.15.2
Libzip version => 1.1.2

zlib

ZLib Support => enabled
Stream Wrapper => compress.zlib://
Stream Filter => zlib.inflate, zlib.deflate
Compiled Version => 1.2.5
Linked Version => 1.2.11

[alcohol]

It's best to use gzip archives and have gzip installed.

[andrerom]

Are you implying I write my own Archiver (if so, anyone have this already?), or that ZipArchive / PharArchive will take advantage of that?

[alcohol]

Oh, wait, this issue is about creating archives. Sorry, that's what you get for digging up ancient stuff 😓

I have no idea. I do not use this functionality myself.

[andrerom]

Yes, and that is why I think this should be opened, maybe a clean new issue with clear info that it's about creating archives.

I have no idea. I do not use this functionality myself.

so you only use satis to generate links to github / ... zipballs, hence act as proxy for composer meta info right?

[alcohol]

I have not used satis in quite a while myself. This project is entirely community maintained.

[alcohol]

I see no reason to (re)open this issue however. Satis does not contain any archiving functionality.

[andrerom]

Maybe not the lib code itself, but it does have archiving features:
https://github.com/composer/satis/blob/master/res/satis-schema.json#L30-L89

But you suggest it's rather reported on composer?

[alcohol]

Indeed. There is no code in Satis that actually generates archives.

[PatrickRose]

@andrerom - what PHP version are you using? You might have got hit with a variant of a bug I hit in PHP's core.

[andrerom]

Nice, missed that bit, so seems to be fixed in:

• 7.3.0
• 7.2.13
• 7.1.25
• 7.0.33

what PHP version are you using?

I was using 7.2.7, so was definitely affected.

[andrerom]

But in my case I had this issue with ZipArchive, so unless it was also fixed there I guess there is still a bug on this somewhere (PHP and/or composer).

[jimmy-ho]

FYI @andrerom your code was correct in resolving the problem, just the reference was off, should be using $localname.

See composer/composer#8330 where I opened up a fix for this.