Skip to content

gh-81881: Raise a shutil.SpecialFileError when copying a Unix socket #16575

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

Closed
wants to merge 6 commits into from

Conversation

AWhetter
Copy link
Contributor

@AWhetter AWhetter commented Oct 4, 2019

This used to raise an OSError with a platform dependent message.
This change always raises a SpecialFileError with a consistent message
no matter the platform.

Tackling special devices wasn't part of the original issue, but it is still technically an issue. Although devices are technically copyable (at least they are with cp), they will likely hang the same as a named pipe would even though a named pipe is technically copyable as well.

https://bugs.python.org/issue37700

This used to raise an OSError with a platform dependent message.
This change always raises a SpecialFileError with a consistent message
no matter the platform.
@brandtbucher
Copy link
Member

brandtbucher commented Oct 4, 2019

Thanks for the PR @AWhetter!

@brandtbucher brandtbucher added the type-feature A feature request or enhancement label Oct 4, 2019
Copy link
Member

@brandtbucher brandtbucher left a comment

Choose a reason for hiding this comment

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

This looks good to me! I would maybe just change the NEWS entry to be less wordy:

:func:`shutil.copyfile` always raises a :exc:`shutil.SpecialFileError` when trying to copy a Unix socket.

@brandtbucher
Copy link
Member

CC @giampaolo @cjerdonek

@AWhetter
Copy link
Contributor Author

AWhetter commented Oct 4, 2019

Good idea. I'll get that changed.
When I make changes to a pull request, is it better for me to edit my existing commit, or should I make a new commit for squashing when the branch is merged?

@brandtbucher
Copy link
Member

I think it helps everyone follow the flow of the PR when things aren't force pushed and history isn't rewritten. It will get squashed in the end, anyways!

I just break up my commits so that the individual diffs are easy to follow. So if I'm editing and moving a function, I'll do those in separate commits in order to preserve an easy-to-follow storyline.

@chrahunt
Copy link
Contributor

Similar to the issue mentioned in bpo-37701, this raises SpecialFileError when src or dest are symlinks to a socket file.

else:
self.fail("shutil.Error should have been raised")
finally:
shutil.rmtree(TESTFN2, ignore_errors=True)
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems unnecessary as per:

 self.addCleanup(shutil.rmtree, TESTFN, ignore_errors=True)

...some lines above.

@@ -663,6 +664,29 @@ def test_copytree_named_pipe(self):
shutil.rmtree(TESTFN, ignore_errors=True)
shutil.rmtree(TESTFN2, ignore_errors=True)

@unittest.skipUnless(hasattr(socket, 'AF_UNIX'), 'requires socket.AF_UNIX')
def test_copytree_socket(self):
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO testing also copytree() is not very useful since internally it uses copyfile (which you are testing).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was copying what was done for named pipes for consistency. But having a test for copytree() makes sense to me because if in the future copytree() stopped using copyfile() for some reason, we would still want copytree() to raise an error?

@@ -54,6 +54,9 @@ Directory and files operations
*dst* and return *dst* in the most efficient way possible.
*src* and *dst* are path-like objects or path names given as strings.

When *src* is a named pipe or a Unix socket, a :exc:`SpecialFileError`
Copy link
Contributor

Choose a reason for hiding this comment

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

-   When *src* is a named pipe or a Unix socket, a :exc:`SpecialFileError`
+   When *src* is a named pipe or a Unix socket, :exc:`SpecialFileError`

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@AWhetter
Copy link
Contributor Author

I have made the requested changes; please review again

@bedevere-bot
Copy link

Thanks for making the requested changes!

@giampaolo: please review the changes made to this pull request.

@bedevere-bot bedevere-bot requested a review from giampaolo May 18, 2020 23:02
@AWhetter
Copy link
Contributor Author

Is there anything else that I can do to help progress this review?

@oz123
Copy link
Contributor

oz123 commented Mar 31, 2023

@giampaolo can this PR be unblocked?

@arhadthedev arhadthedev changed the title bpo-37700: Raise a shutil.SpecialFileError when copying a Unix socket gh-81881: Raise a shutil.SpecialFileError when copying a Unix socket Mar 31, 2023
@arhadthedev arhadthedev added the stdlib Python modules in the Lib dir label Mar 31, 2023
@oz123
Copy link
Contributor

oz123 commented Mar 31, 2023

@arhadthedev thanks for the quick response!

@arhadthedev
Copy link
Member

arhadthedev commented Mar 31, 2023

shutil.SpecialFileError seems to be undocumented. Would anybody add it into the documentation via a separate PR?

@AWhetter AWhetter closed this Jul 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting change review stdlib Python modules in the Lib dir type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants