Feature: Add support to file.managed (and others) to preserve the file inode

[tkent-xetus]

When file.managed is used, every time the file is updated the inode of the file is changed. This breaks things like hardlinks and file-based docker volume mounts. It's not terribly difficult to work around, but it's awfully hard to figure out what's happening. In our case, files mounted into a docker container, that were managed by salt, were not reflecting changes in the docker container after salt modified them.

Once you know the cause, the impact is very small. The work around is very easy, just a two step process like so:

managed-file-where-inode-changes:
  file.managed:
    - source: salt://some/file.cfg
    - template: jinja

file-where-innod-will-not-change:
  require:
    - file: managed-file-where-inode-changes
  cmd.wait:
    - name: cat managed-file-where-inode-changes > file-where-innod-will-not-change
    - watch:
      - file: managed-file-where-inode-changes

However, it looks like this issue was already broached in #20969, so tools exist in salt to handle this scenario. It would be great if there was a property on file.managed, and similar states, like preserve_inode that had a True default.

[lorengordon]

Hi @tkent-xetus, that feature was merged into the file.replace module in the develop branch, so it should be out in the next major version of salt. I thought the file.replace state would support passing the preserve_inode parameter via kwargs, but it seems kwargs hasn't been added to the file.replace state.

I hadn't looked into how file.managed handles files, so someone will have to do a little investigation into preserving the inode there. Typically, I've found the problem around inodes is that the file is copied and any changes are made to the copy, and then the files are renamed so the copy has the same filename as the original, but because it's still a copy it has a different inode. What I did in file.replace is make a copy as a backup, then modify the original in place. I would presume that something similar needs to happen for file.managed and the functions it calls.

[tkent-xetus]

@lorengordon

Cool, sounds like we're on the same page! The copy vs update thing is exactly what's happening in the file.managed state code (and the file.manage module code). I went ahead and traced the code in the 2015.5.0 branch originally, and I just confirmed that this feature is not in the develop branch now.

--- update - fixed unclear comment ---

[jfindlay]

@tkent-xetus, thanks for the report. You are welcome to close this when you think the issue is resolved.

[tkent-xetus]

@jfindlay

I think I've caused some confusion - my last comment wasn't well written, I just updated/clarified it. The feature being requested here is not currently in the develop branch.

[lorengordon]

@jfindlay, sorry if I added to any confusion, but I don't think this is fixed at all, unfortunately. Some work will need to be done within file.managed and the various functions it calls to support this feature. Hopefully it's not too difficult, as the issue with the existing approach has been identified, and there are some tools in place (e.g. _mkstemp_copy()) that may help.

[jfindlay]

@tkent-xetus, @lorengordon, thanks for the extra information.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[tkent]

I think this should remain open. While it's not a huge issue, it would be a very useful feature.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[markdoliner]

(Echoing @tkent's comment from a year ago:) I think this should remain open. While it's not a huge issue, it would be a very useful feature.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[kislik]

Hello! What about this feature?
The question is still very actually, especially for docker's containers.
If file.managed will change inode number on a host machine it will impact on a docker container with this file (volume). And it means that any future changes in the file (on the host machine) will not affect the file inside the docker.

Four years passed. =)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[markdoliner]

Still a good idea.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[jtoops009]

This feature is needed. Without the feature, managing bind-chroot config files does not work correctly.

[epelc]

This is still a problem when working with docker bind mounts to a single file. Any chance file.managed gets support for preserve_inode?