When changing file permission the file is only created after second time apply

[hmmlopez]

Terraform CLI and Provider Versions

Terraform v1.3.2
on linux_amd64

• provider registry.terraform.io/hashicorp/local v2.2.3
• provider registry.terraform.io/hashicorp/random v3.4.3

Terraform Configuration

resource "local_file" "pet" {
  filename = var.filename
  content = "My favorite pet is ${random_pet.my-pet.id}!"
  file_permission = "0700"
  
  lifecycle {
    create_before_destroy = true
  }
}

resource "random_pet" "my-pet" {
  prefix = var.prefix
  separator = var.separator
  length = var.length
}

Expected Behavior

Expected a file to be generated after running one time the command terraform apply when changing the file permission of an existing file. Seems it deletes the old file but a new file is not being created. After running terraform apply for second I see the new file is being created. No error is thrown after the first time running the apply method.

Actual Behavior

After 1 time terraform apply the file gets removed and no new file is created.

Steps to Reproduce

1. terraform apply to create a new file
2. change the file permission of that file
3. 'terraform apply' to apply the new permission, the file is being removed and runs sucessfully ( no new file is being created )
4. 'terraform apply' again to create a new file, this should be already handled in step 3.

How much impact is this issue causing?

Low

Logs

No response

Additional Information

Think this bug is only when using the lifecycle create_before_destroy.

Code of Conduct

• I agree to follow this project's Code of Conduct

[jo2y-tock]

I am seeing something similar except it's when the contents of the file change. I'm having trouble reproducing it on a small scale, but in my case the local_file resource is buried a few modules deep.

I do notice when I run terraform apply that a destruction event happens after the create event.

module.mod1.module.mod2.module.mod3.local_file.file: Creating...
[snip]
module.mod1.module.mod2.module.mod3.local_file.file: Creation complete after 0s [id=9daacaf1327023d49de76337a798ffe0ff8808f3]
[snip]
module.mod1.module.mod2.module.mod3.local_file.file (deposed object f537c4fb): Destroying... [id=6603365d67f2ce41538eefc330e6e6150ec6537d]
[snip]
module.mod1.module.mod2.module.mod3.local_file.file: Destruction complete after 0s

If I try terraform apply -target module.mod1.module.mod2.module.mod3.local_file.file`, the ordering is correct.

If it matters, my filenames are directory/filename.ext and there are multiple files being written to the same directory. I did try to -target 2 files in that directory, but that worked as expected as well.

I predict the deposed object f537c4fb is the key and some form of object garbage collection is triggering the deletion phase instead of the normal plan methods.

I've tested with terraform 1.3.0, 1.3.1 and 1.3.2 as well as local module versions 2.2.2 and 2.2.3.

Early in my testing I did try create_before_destory = false, but it was not used otherwise.

[dmbrownlee]

Looks like terraform does not manage file permissions. The file_permissions attribute is used when terraform creates the file, but it does not attempt to manage those permissions once the file exists. That is, if terraform creates the file with "0644" and you chmod 777 the file outside of terraform, terraform will not notice the change and fix the permissions on future runs of "terraform apply". Similarly, "terraform refresh" also does not update state with the actual file permissions.

terraform 1.5.7.

[apparentlymart]

I don't think this problem is permissions-related. The problem is that this is not a reasonable situation to use create_before_destroy = true.

The create_before_destroy feature requires that the provider be able to support having both the new and old objects existing at the same time, but that isn't possible for local_file because there can't be two files with the same filename at the same time.

Therefore I expect Terraform is effectively performing the following sequence of actions:

1. Create the new file (overwriting the old one in the process, because that's how the local filesystem works)
2. Delete what the provider thinks is the old file, but is actually now the new file, because the previous step just overwrote the old file.

This is one of the hazards of using Terraform to manage files, since Terraform is really designed for managing objects via network APIs.

Avoiding the use of create_before_destroy should instead cause the necessary ordering, where the old file gets deleted first and then the new one created in its place. The create_before_destroy option is "sticky" in the Terraform state -- the old objects "remembers" that it was a create-before-destroy object -- so you may need to run two plan/apply rounds for the change to take effect.

Another option is to make sure each new version of the file has a different filename, in which case Terraform will be able to create the new one without overwriting the old one and can then delete the old one safely.