Writing file uses new inode, breaking Docker mounts

[KetchupBomb]

It appears that docker-gen creates a new temporary file that is then moved to [dest], based at least on differing inodes.

Consider the following REPL:

$ docker run -it --rm -v /var/run/docker.sock:/tmp/docker.sock:ro --entrypoint ash nginxproxy/docker-gen
$ echo '{{- . -}}' > template.tmpl

$ docker-gen template.tmpl rendered.txt
2024/05/28 07:49:25 Generated 'rendered.txt' from 111 containers
$ stat rendered.txt 
  File: rendered.txt
  Size: 1444            Blocks: 8          IO Block: 4096   regular file
Device: 7bh/123d        Inode: 32639413    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-05-28 07:49:25.310417663 +0000
Modify: 2024-05-28 07:49:25.310417663 +0000
Change: 2024-05-28 07:49:25.310417663 +0000

$ docker-gen template.tmpl rendered.txt
2024/05/28 07:49:29 Generated 'rendered.txt' from 111 containers
$ stat rendered.txt 
  File: rendered.txt
  Size: 1444            Blocks: 8          IO Block: 4096   regular file
Device: 7bh/123d        Inode: 32639416    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-05-28 07:49:29.858497954 +0000
Modify: 2024-05-28 07:49:29.858497954 +0000
Change: 2024-05-28 07:49:29.858497954 +0000

(The inode changes from 32639413 to 32639416.)

This can cause processes with open file descriptors to continue reading the old inode. Of particular interest are Docker mounts.

I have been trying to leverage docker-gen to render config files, and I then share those config files to other contains, ideally mounting just the rendered config files as them directly into the receiving containers filesystem as :ro. (Trying to be secure 🤷‍♂️)

But due to the above behavior, the receiving container never sees the new rendered config -- it continues reading the old inode and therefore old data.

This isn't necessarily a bug with docker-gen -- I fixed it for now by not mounting the file directly, but rather mounting the file's directory which alleviates the issue -- but truncating the existing inode and writing directly would have helped me out recently. Thanks for considering this issue.

[buchdag]

Hi @KetchupBomb

I know this is issue is almost 9 months old but #665 should finally fix it, as it write newly rendered content straight to the destination file instead of creating then moving a temp file (so the files's inode should not change anymore).

Would you be interested in testing it ?