Skip to content

Fix divergent overwrite behavior of FileManager.copyItem(at:to:) on Linux and Windows #4821

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

Merged
merged 2 commits into from
Sep 16, 2023
Merged

Fix divergent overwrite behavior of FileManager.copyItem(at:to:) on Linux and Windows #4821

merged 2 commits into from
Sep 16, 2023

Conversation

gwynne
Copy link
Contributor

@gwynne gwynne commented Sep 16, 2023

On Apple platforms, the FileManager APIs copyItem(atPath:toPath:) and copyItem(at:to:) refuse to overwrite the destination file (or link, or directory) if it already exists; this behavior is even explicitly documented. And indeed, any such attempt results in a fileWriteFileExists error.

However, on Linux and Windows, the destination is silently overwritten. This PR changes that behavior to match what's documented. On POSIX platforms, this is accomplished by adding the O_EXCL flag to the relevant open(2) call, which results in an EEXIST errno if the path already exists. For Windows, the bFailIfExists parameter of CopyFileW() is changed to true.

Fixes #3368

(This is a recreation of #4808, which was closed accidentally.)

@gwynne
Copy link
Contributor Author

gwynne commented Sep 16, 2023

@parkera My apologies for the mistaken deletion of the original PR; can you re-review?

@compnerd
Copy link
Member

@swift-ci please test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[SR-11963] FileManager.copyItem doesn't fail when there already is an item at destination path
2 participants