Re: [Python-Dev] [Python-checkins] cpython: Issue #12715: Add an optional symlinks argument to shutil functions (copyfile,
On Thu, Dec 29, 2011 at 11:55, antoine.pitrou
http://hg.python.org/cpython/rev/cf57ef65bcd0 changeset: 74194:cf57ef65bcd0 user: Antoine Pitrou
date: Thu Dec 29 18:54:15 2011 +0100 summary: Issue #12715: Add an optional symlinks argument to shutil functions (copyfile, copymode, copystat, copy, copy2). When that parameter is true, symlinks aren't dereferenced and the operation instead acts on the symlink itself (or creates one, if relevant). Patch by Hynek Schlawack.
files: Doc/library/shutil.rst | 46 ++++- Lib/shutil.py | 101 +++++++++--- Lib/test/test_shutil.py | 219 ++++++++++++++++++++++++++++ Misc/NEWS | 5 + 4 files changed, 333 insertions(+), 38 deletions(-)
diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst --- a/Doc/library/shutil.rst +++ b/Doc/library/shutil.rst @@ -45,7 +45,7 @@ be copied.
-.. function:: copyfile(src, dst) +.. function:: copyfile(src, dst[, symlinks=False])
Copy the contents (no metadata) of the file named *src* to a file named *dst*. *dst* must be the complete target file name; look at :func:`copy` for a copy that @@ -56,37 +56,56 @@ such as character or block devices and pipes cannot be copied with this function. *src* and *dst* are path names given as strings.
+ If *symlinks* is true and *src* is a symbolic link, a new symbolic link will + be created instead of copying the file *src* points to. + .. versionchanged:: 3.3 :exc:`IOError` used to be raised instead of :exc:`OSError`. + Added *symlinks* argument.
Can we expect that readers on Windows know how os.symlink works, or should the stipulations of os.symlink usage also be laid out or at least linked to from there? Basically, almost everyone is going to get an OSError if they call this on Windows. You have to be on Windows Vista or beyond *and* the calling process has to have the proper privileges (typically gained through elevation - "Run as Administrator").
On Fri, 30 Dec 2011 13:29:36 -0600
Brian Curtin
Can we expect that readers on Windows know how os.symlink works, or should the stipulations of os.symlink usage also be laid out or at least linked to from there?
I assume it won't make a difference in real life, since symlinks are quite rare under Windows.
Basically, almost everyone is going to get an OSError if they call this on Windows. You have to be on Windows Vista or beyond *and* the calling process has to have the proper privileges (typically gained through elevation - "Run as Administrator").
I still haven't managed to use symlinks under Windows 7, myself. The recipes I've tried didn't work. Regards Antoine.
On Fri, Dec 30, 2011 at 13:39, Antoine Pitrou
On Fri, 30 Dec 2011 13:29:36 -0600 Brian Curtin
wrote: Can we expect that readers on Windows know how os.symlink works, or should the stipulations of os.symlink usage also be laid out or at least linked to from there?
I assume it won't make a difference in real life, since symlinks are quite rare under Windows.
Basically, almost everyone is going to get an OSError if they call this on Windows. You have to be on Windows Vista or beyond *and* the calling process has to have the proper privileges (typically gained through elevation - "Run as Administrator").
I still haven't managed to use symlinks under Windows 7, myself. The recipes I've tried didn't work.
This might be a place where an image in the documentation would be helpful. I don't think we do that anywhere else, but maybe I could add it to the (sorely out of date and in need of a rebuild) Windows FAQ? What you need to do on Win7 is go to Start > All Programs > Accessories > Command Prompt, but right click on it instead of left click. Choose "Run as Administrator", then it'll make you choose yes or no to elevate privileges. At that point, deep in the heart of everyone's favorite operating system, it should acquire the SeCreateSymbolicLink user privilege. After that, os.symlink should work fine.
participants (2)
-
Antoine Pitrou
-
Brian Curtin