Examples:

- drwxrwxrwx vsts/docker       0 2019-04-06 19:09 ldc2-1.15.0-linux-x86_64/etc/

  issues:

     · directory not root:root owned
     · directory group and world writable

- -rwxrwxrwx 1001/117    1552408 2019-04-06 19:10 ldc2-1.15.0-linux-x86_64/bin/ddemangle


  issues:

     · file not root:root owned
     · file group and world writable

vsts/docker is uid/gid 1001/117. If you untar the tarball the files are created with this uid/gid.

Expected: All files and directories have uid/gid 0/0 (root/root) and are not group and not world writable.

Hi,

On 8 Apr 2019, at 18:52, kdevel via digitalmars-d-ldc wrote:
>      · directory not root:root owned
>      · directory group and world writable

Is this actually an issue? I agree 0:0 would be a bit cleaner, but what are the situations where this isn't easily fixed after extraction? The release configuration is at https://github.com/ldc-developers/ldc/blob/master/shippable.yml, if you'd like to submit a pull request.

Best,
David

On Monday, 8 April 2019 at 21:54:05 UTC, David Nadlinger wrote:
> Is this actually an issue? I agree 0:0 would be a bit cleaner, but what are the situations where this isn't easily fixed after extraction? The release configuration is at https://github.com/ldc-developers/ldc/blob/master/shippable.yml, if you'd like to submit a pull request.

As far as I understand, this is by default only a concern when extracting as root. Anway, PR is already up (for Azure, as that's the culprit; Shippable is unchanged and exactly as desired - 0:0 and 644/755): https://github.com/ldc-developers/ldc/pull/3056

Thanks @kdevel for noticing, although a bit too late. ;)