pyinfra icon indicating copy to clipboard operation
pyinfra copied to clipboard

files.download does not correct the file mode

Open RichardKraus opened this issue 1 year ago • 0 comments

Describe the bug

files.download does not correct the mode of already existing files, even if they differ from the specified ones. The outcome of the operation is therefore dependent on the state of the machine before the operation, and may differ from the state requested in the operation. I would consider this a bug.

To Reproduce

$ pyinfra -y @local files.download https://get.k3s.io ./here mode=u=rw
[...]
$ ll here
-rw-r--r-- 1 rickra rickra 36K Sep  7 08:00 here
$ pyinfra -y @local files.download https://get.k3s.io ./here mode=777
[...]
$ ll here  # here, the permissions should be adjusted, but arent
-rw-r--r-- 1 rickra rickra 36K Sep  7 08:00 here
$ rm here
$ pyinfra -y @local files.download https://get.k3s.io ./here mode=777
[...]
$ ll here
-rwxrwxrwx 1 rickra rickra 36K Sep  7 08:04 here

This is because files.download only checks if any file exists or the hashes differ from optionally supplied ones. There should be an additional mode check.

Expected behavior

If the file mode differs, the file mode should at least be adjusted to match the requested mode. I would personally argue that the file should be redownloaded when the mode argument is changed, since I would translate the operation name "download" as "download if the state does not match the expected" (as in file does not exist, file too old, ...).

RichardKraus avatar Sep 07 '24 06:09 RichardKraus