safing-portmaster/base/utils/renameio
Vladimir Stoilov 943b9b7859
Fix file permissions on windows ()
* [service] Set file permissions on windows

* [service] Fix minor windows permission bugs

* [service] Fix permission bugs

* [service] Fix windows non admin user start
2024-11-26 17:00:01 +02:00
..
doc.go Restructure modules () 2024-08-09 18:15:48 +03:00
example_test.go Restructure modules () 2024-08-09 18:15:48 +03:00
LICENSE Restructure modules () 2024-08-09 18:15:48 +03:00
README.md Restructure modules () 2024-08-09 18:15:48 +03:00
symlink_test.go Restructure modules () 2024-08-09 18:15:48 +03:00
tempfile.go Restructure modules () 2024-08-09 18:15:48 +03:00
tempfile_linux_test.go Restructure modules () 2024-08-09 18:15:48 +03:00
writefile.go Fix file permissions on windows () 2024-11-26 17:00:01 +02:00
writefile_test.go Restructure modules () 2024-08-09 18:15:48 +03:00

This is a fork of the github.com/google/renameio Go package at commit 353f8196982447d8b12c64f69530e657331e3dbc.

The inital commit of this package will carry the original package contents.
The Original License is the Apache License in Version 2.0 and the copyright of the forked package is held by Google Inc.
Any changes are recorded in the git history, which is part of this project.


The renameio Go package provides a way to atomically create or replace a file or symbolic link.

Atomicity vs durability

renameio concerns itself only with atomicity, i.e. making sure applications never see unexpected file content (a half-written file, or a 0-byte file).

As a practical example, consider https://manpages.debian.org/: if there is a power outage while the site is updating, we are okay with losing the manpages which were being rendered at the time of the power outage. They will be added in a later run of the software. We are not okay with having a manpage replaced by a 0-byte file under any circumstances, though.

Advantages of this package

There are other packages for atomically replacing files, and sometimes ad-hoc implementations can be found in programs.

A naive approach to the problem is to create a temporary file followed by a call to os.Rename(). However, there are a number of subtleties which make the correct sequence of operations hard to identify:

  • The temporary file should be removed when an error occurs, but a remove must not be attempted if the rename succeeded, as a new file might have been created with the same name. This renders a throwaway defer os.Remove(t.Name()) insufficient; state must be kept.

  • The temporary file must be created on the same file system (same mount point) for the rename to work, but the TMPDIR environment variable should still be respected, e.g. to direct temporary files into a separate directory outside of the webservers document root but on the same file system.

  • On POSIX operating systems, the fsync system call must be used to ensure that the os.Rename() call will not result in a 0-length file.

This package attempts to get all of these details right, provides an intuitive, yet flexible API and caters to use-cases where high performance is required.

Disclaimer

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

This project is not affiliated with the Go project.