[PATCH proxmox-backup] pbs-key-config: align fsync behavior when storing new/existing key

[PATCH proxmox-backup] pbs-key-config: align fsync behavior when storing new/existing key

[Christian Ebner]

In case a key is stored by replacing the file contents, the file
contents are synced to disk as the corresponding flag is set for
proxmox-sys::fs::replace_file(). When creating a new file however,
fsync is never called.

Align the behaviour by also calling fsync in case of storing the key
to a new file.

Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
---
Noticed while evaluating to reuse this method to store key
information to be used by push sync jobs.

 pbs-key-config/src/lib.rs | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/pbs-key-config/src/lib.rs b/pbs-key-config/src/lib.rs
index 0bcd5338c..71a49dd78 100644
--- a/pbs-key-config/src/lib.rs
+++ b/pbs-key-config/src/lib.rs
@@ -1,5 +1,6 @@
 use std::io::Write;
 use std::path::Path;
+use std::os::fd::AsRawFd;
 
 use anyhow::{bail, format_err, Context, Error};
 use serde::{Deserialize, Serialize};
@@ -254,6 +255,7 @@ impl KeyConfig {
                     .open(path)?;
 
                 file.write_all(data.as_bytes())?;
+                nix::unistd::fsync(file.as_raw_fd())?;
             }
 
             Ok(())
-- 
2.47.3

Re: [PATCH proxmox-backup] pbs-key-config: align fsync behavior when storing new/existing key

[Fabian Grünbichler]

On March 24, 2026 11:04 am, Christian Ebner wrote:
> In case a key is stored by replacing the file contents, the file
> contents are synced to disk as the corresponding flag is set for
> proxmox-sys::fs::replace_file(). When creating a new file however,
> fsync is never called.
> 
> Align the behaviour by also calling fsync in case of storing the key
> to a new file.
> 
> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
> ---
> Noticed while evaluating to reuse this method to store key
> information to be used by push sync jobs.
> 
>  pbs-key-config/src/lib.rs | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/pbs-key-config/src/lib.rs b/pbs-key-config/src/lib.rs
> index 0bcd5338c..71a49dd78 100644
> --- a/pbs-key-config/src/lib.rs
> +++ b/pbs-key-config/src/lib.rs
> @@ -1,5 +1,6 @@
>  use std::io::Write;
>  use std::path::Path;
> +use std::os::fd::AsRawFd;
>  
>  use anyhow::{bail, format_err, Context, Error};
>  use serde::{Deserialize, Serialize};
> @@ -254,6 +255,7 @@ impl KeyConfig {
>                      .open(path)?;
>  
>                  file.write_all(data.as_bytes())?;
> +                nix::unistd::fsync(file.as_raw_fd())?;

LGTM in principle, though we could also switch to
atomic_open_or_create_file ?

>              }
>  
>              Ok(())
> -- 
> 2.47.3
> 
> 
> 
> 
> 
> 

Re: [PATCH proxmox-backup] pbs-key-config: align fsync behavior when storing new/existing key

[Christian Ebner]

On 3/24/26 2:16 PM, Fabian Grünbichler wrote:
> On March 24, 2026 11:04 am, Christian Ebner wrote:
>> In case a key is stored by replacing the file contents, the file
>> contents are synced to disk as the corresponding flag is set for
>> proxmox-sys::fs::replace_file(). When creating a new file however,
>> fsync is never called.
>>
>> Align the behaviour by also calling fsync in case of storing the key
>> to a new file.
>>
>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
>> ---
>> Noticed while evaluating to reuse this method to store key
>> information to be used by push sync jobs.
>>
>>   pbs-key-config/src/lib.rs | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/pbs-key-config/src/lib.rs b/pbs-key-config/src/lib.rs
>> index 0bcd5338c..71a49dd78 100644
>> --- a/pbs-key-config/src/lib.rs
>> +++ b/pbs-key-config/src/lib.rs
>> @@ -1,5 +1,6 @@
>>   use std::io::Write;
>>   use std::path::Path;
>> +use std::os::fd::AsRawFd;
>>   
>>   use anyhow::{bail, format_err, Context, Error};
>>   use serde::{Deserialize, Serialize};
>> @@ -254,6 +255,7 @@ impl KeyConfig {
>>                       .open(path)?;
>>   
>>                   file.write_all(data.as_bytes())?;
>> +                nix::unistd::fsync(file.as_raw_fd())?;
> 
> LGTM in principle, though we could also switch to
> atomic_open_or_create_file ?

Had a look at that as well, that would however create a tempfile first. 
And since we do already have the open file descriptor here and handle 
failure on per-existing files here as expected (which would require 
adding `OFlag::O_EXCL` in the other case), I did not consider this 
further, simply calling fsync seemed the better option for this 
particular case.