Freeze file times on Windows

[tguichaoua]

Proposal

Problem statement

On Windows, I want to open and modify a file without altering the "last access time" and "last write time" of the file.

Motivating examples or use cases

In my use case I want to edit an Alternate Data Stream (ADS) without the "last write time" of the parent file being changed. In short, an ADS is a hidden file attached to a normal file. Editing an ADS will affect the "list write time" of the file it is attached to, which is what I want to prevent.

Solution sketch

The Windows API provide a method SetFileTime that, with the appropriate parameters and a file handle, prevent the file's "last access time" and "last write time" to be modified by futher access on the file handle.

I propose to add two new methods to OpenOptionsExt (names bikesheddable):

• freeze_last_access_time: if set to true, prevent the "last access time" of the file from being changed, default to false
• freeze_last_write_time: if set to true, prevent the "last write time" of the file from being changed, default to false

Then in the open_native function, if at least one of the freeze_last_access_time or freeze_last_write_time flag is set, we call SetFileTime just after the CreateFileW in order to ensure the times are not modified.

Alternatives

It's possible to achieve this with the current API by calling the following function on a File:

fn freeze_file_time<T>(file: &T) -> io::Result<()>
where
    T: AsRawHandle + ?Sized,
{
    let filetime = FILETIME {
        dwLowDateTime: 0xFFFFFFFF,
        dwHighDateTime: 0xFFFFFFFF,
    };

    let result = unsafe {
        SetFileTime(
            file.as_raw_handle(),
            core::ptr::null(),
            &filetime,
            &filetime,
        )
    };

    if result == 0 {
        Err(io::Error::last_os_error())
    } else {
        Ok(())
    }
}

The problem is that, when using truncate(true), the standard API is performing a manual truncate before returning the file handler which prevent the user to call freeze_file_time before any change happen to the file.
The alternative is to do so:

let mut file = fs::File::options()
        .create(true)
        .write(true)
        .truncate(false)
        .open(path)?;

freeze_file_time(&file)?;

file.set_len(0)?;

But it results into something less ergonomic.

Links and related work

• https://internals.rust-lang.org/t/pre-rfc-acp-windows-freeze-file-times/23787

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[ChrisDenton]

I would note that CreateFileW also updates the write time when using TRUNCATE_EXISTING so our manual truncation is what would make this possible in that case.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting, and we were in favor of adding these to the OptionOptionsExt extension trait.

Please close the ACP when you've opened a tracking issue.