Skip to content
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

archive_file changes file permissions on Windows #58

Closed
KyleKotowick opened this issue Dec 25, 2019 · 6 comments
Closed

archive_file changes file permissions on Windows #58

KyleKotowick opened this issue Dec 25, 2019 · 6 comments

Comments

@KyleKotowick
Copy link

This is a re-opening of issue #10 .

This issue is still occurring on Windows. Within the ZIP file created by archive_file when running Terraform v0.12.18 with AWS provider v2.43 on Windows 10, the contained file has 666 permissions (no execute). Running the exact same Terraform plan with the same version on Linux results in the contained file having 777 permissions.

@KyleKotowick KyleKotowick changed the title rchive_file changes file permissions on Windows archive_file changes file permissions on Windows Dec 28, 2019
@RichardBradley
Copy link

I have a similar or the same issue.
I am creating a zip file for a Lambda with code like this:

data "archive_file" "my_lambda_zip" {
  type        = "zip"
  output_path = "${path.root}/.terraform/tmp/my_lambda.zip"
  source_file = "${path.module}/my-src.js"
}

The "my-src.js" file is a regular file in git:

$ git ls-files -s my-src.js
100644 8ef1d00576701a5cbd7c07c0f5496131b4554b43 0       my-src.js

On unix, the output of the "archive_file" is a zip containing a 644 / "-rw-r--r--" file:

$ zipinfo my_lambda.zip
Archive:  my_lambda.zip
Zip file size: 1064 bytes, number of entries: 1
-rw-r--r--  2.0 unx     2001 bl defN 49-Jan-01 00:00 my-src.js
1 file, 2001 bytes uncompressed, 876 bytes compressed:  56.2%

On windows, the file permissions are different:

zipinfo my_lambda.zip
Archive:  my_lambda.zip
Zip file size: 1064 bytes, number of entries: 1
-rw-rw-rw-  2.0 unx     2001 bl defN 49-Jan-01 00:00 my-src.js
1 file, 2001 bytes uncompressed, 876 bytes compressed:  56.2%

This causes Terraform to unnecessarily mark the Lambda as changed, as I am using "filebase64sha256" on the zip, which differs by this one byte.

How can I persuade archive_file to generate a 644/"-rw-r--r--" file on Windows (or indeed a 666/"-rw-rw-rw-" file on Unix)?

Thanks

@RichardBradley
Copy link

RichardBradley commented Mar 16, 2021

It looks like the code that handles this reads the file perms using Go's "os.stat" at archiver.go:28 and hands that file mode off directly to Go's zip.FileInfoHeader at zip_archiver.go:56.

According to this blog, Go will always report either 666 or 444 file mode on Windows. Whereas the actual permissions on unix are typically 644.

So without a windows-specific workaround to archive_file, I will need to arrange for my file to be 666 on unix to make my builds consistent cross-platform.

@RichardBradley
Copy link

It looks like git won't allow me to make the file 666 mode, only 644 or 755 (cite).
So I'm going to struggle to get this to behave the same on unix and windows without some kind of helper script

@kmoe
Copy link
Member

kmoe commented May 5, 2021

The workaround in #90 has been released in terraform-provider-archive v2.2.0. If output_file_mode does not solve your problem, please comment on this issue or open a new one.

@kmoe kmoe closed this as completed May 5, 2021
@RichardBradley
Copy link

Thanks, that workaround fixes this for me!

Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants