We could implement this in a way that isn't blocked by 7394 and 7395. Just open the contents file in mode 0640 instead of 0440 (since we have to write to it anyways), then after we're done change the mode to 0440 (or leave it writable by owner).
We should use Puppet::Util.replace_file when the server writes the contents and paths files in the file bucket. This is best tested by running multiple agents and have them backup the same sets of files concurrently. If we are not atomically updating files, then you should warnings to the effect of "FileBucket got a duplicate file" and "Unable to verify FileBucket backup", and "Existing backup does not match its expected sum"
We should use Puppet::Util.replace_file when the server writes the contents and paths files in the file bucket. This is best tested by running multiple agents and have them backup the same sets of files concurrently. If we are not atomically updating files, then you You should see warnings to the effect of "FileBucket got a duplicate file" and you will never see "Unable to verify FileBucket backup", and "Existing backup does not match its expected sum"
We should use Puppet::Util.replace_file when the server writes the contents and paths files in the file bucket. This is best tested by running multiple agents and have them backup the same sets of files concurrently. You should see warnings to the effect of "FileBucket got a duplicate file" and you will should never see "Unable to verify FileBucket backup", and "Existing backup does not match its expected sum"
We should use Puppet::Util.replace_file whenWhile uploading a large file to the server writes filebucket, attempting to retrieve a file with the contents and paths files in same hash from the filebucket should not result in partial file bucket content. This is best tested by running multiple agents and have them backup the same sets of files concurrently. You should see warnings to either get no content, in the effect of "FileBucket got case where it's a duplicate new file" and, or you should never see "Unable to verify FileBucket backup", and "Existing backup does not match its expected sum" get the complete file in the case where the file was already existing in the filebucket.
File bucket contents are now atomically updated, this resolves a race condition where retrieving a file from the file bucket could result in retrieving a partial file.