Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle 'atomically' created files more gracefully when detached #2682

Merged
merged 3 commits into from Mar 15, 2024

Conversation

glbrntt
Copy link
Contributor

@glbrntt glbrntt commented Mar 13, 2024

Motivation:

When a file is created 'atomically' and the descriptor is detached from its handle then the user is provided with the descriptor for a temporary file, and the desired file is never created.

Modifications:

Where supported, atomically created files use a temporary unnamed file which is then linked on close. Elsewhere a temporary named file is created which is renamed on closed.

Temporary unnamed files are linked in detach but not closed. Temporary named files are linked to the desired path before being unlinked.

  • Break out the logic for materializing a file created using a temporary unnamed file
  • Add syscalls and error mappings for link(2) and unlink(2)

Result:

Atomically created files behave as expected when detached

Motivation:

When a file is created 'atomically' and the descriptor is detached from
its handle then the user is provided with the descriptor for a temporary
file, and the desired file is never created.

Modifications:

Where supported, atomically created files use a temporary unnamed file
which is then linked on close. Elsewhere a temporary named file is
created which is renamed on closed.

Temporary unnamed files are linked in detach but not closed. Temporary
named files are linked to the desired path before being unlinked.

- Break out the logic for materializing a file created using a temporary
  unnamed file
- Add syscalls and error mappings for link(2) and unlink(2)

Result:

Atomically created files behave as expected when detached
@glbrntt glbrntt added the patch-version-bump-only For PRs that when merged will only cause a bump of the patch version, ie. 1.0.x -> 1.0.(x+1) label Mar 13, 2024
@glbrntt glbrntt requested a review from gjcairo March 13, 2024 16:09
from source: FilePath,
to destination: FilePath
) -> Result<Void, Errno> {
return nothingOrErrno(retryOnInterrupt: false) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How sure are we that not retrying here is appropriate?

Sources/NIOFileSystem/Internal/SystemFileHandle.swift Outdated Show resolved Hide resolved
@glbrntt glbrntt requested a review from Lukasa March 15, 2024 10:03
@glbrntt glbrntt merged commit 1e2b3e3 into apple:main Mar 15, 2024
8 of 9 checks passed
@glbrntt glbrntt deleted the detached branch March 15, 2024 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
patch-version-bump-only For PRs that when merged will only cause a bump of the patch version, ie. 1.0.x -> 1.0.(x+1)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants