Also add an explicit test for safe implementation usage on supported platforms.
As a side effect, this commit adds a module-level attribute 'rmtree_is_safe'
which offers introspection whether the current rmtree implementation is safe
against symlink attacks.
Many functions now support "dir_fd" and "follow_symlinks" parameters;
some also support accepting an open file descriptor in place of of a path
string. Added os.support_* collections as LBYL helpers. Removed many
functions only previously seen in 3.3 alpha releases (often starting with
"f" or "l", or ending with "at"). Originally suggested by Serhiy Storchaka;
implemented by Larry Hastings.
and the source is a symlink, shutil.move() now recreates a symlink on the
destination instead of copying the file contents.
Patch by Jonathan Niehof and Hynek Schlawack.
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.
The tests now have two convenience functions to wrap os.path.join, open
and read or write instead of four or six slightly different functions.
The new functions accept a tuple of path segments but not a list
anymore, as it makes no sense to use a list here; I have also removed
the default value for the contents in write_file, as I find it better to
have the contents at the call site.
For simple open then read/write calls, I have left the usual idiom (with
open + read/write), as it is short and readable enough.
I’ve also changed some convoluted cleanup code to just use rmtree, and
removed dubious LBYL os.path.exists checks. The tests still pass on my
machine, and leave no file in $TMP. test_shutil is not as clean as it
could be, but I’ll stop here.
Initial patch provided by Hynek Schlawack, in preparation for a new
feature with new tests in #12715.
We don't need to create a temporary buffered binary or text file object just to
create an empty file.
Replace also os.fdopen(handle).close() by os.close(handle).
In order to create symlinks on Windows, SeCreateSymbolicLinkPrivilege
is an account privilege that is required to be held by the user. Not only
must the privilege be enabled for the account, the activated privileges for
the currently running application must be adjusted to enable the requested
privilege.
Rather than exposing an additional function to be called prior to the user's
first os.symlink call, we handle the AdjustTokenPrivileges Windows API call
internally and only expose os.symlink when the privilege escalation was
successful.
Due to the change of only exposing os.symlink when it's available, we can
go back to the original test skipping methods of checking via `hasattr`.