Path.mkdir() can't create a directory with cleared write or list permission bits for owner when parent directories aren't created. This is because for parent directories same mode is used as for final directory.

To support this use case we should implicitly set write and list permission bits for owner when creating parent directories.

I don't know if this work on Windows.

Wouldn't it be better to throw an error rather than create a (parent) directory with possibly wrong permission bits? It seems like this would require an unusual use case in any event.

The mkdir utility creates parent directories with mode 0o777 & ~umask.

$ mkdir -p -m 0 t1/t2/t3
$ ls -l -d t1 t1/t2 t1/t2/t3
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/t2/
d--------- 2 serhiy serhiy 4096 Dec  7 22:30 t1/t2/t3/

So perhaps we should just use 0o777 mode for parent directories.

OK, emulating mkdir -p seems like the sensible thing to do. That's the least likely to be surprising.

Updated patch emulates the mkdir utility.

Updated patch addresses Antoine's comments.

Patch looks good to me. Do you think the documentation should be clarified a bit?

Yes, please clarify the documentation.

Perhaps we should add new argument parents_mode?

A new argument sounds overkill to me.

Fails on Windows Vista.

...................................................s..s..s..s.......F.
......
======================================================================
FAIL: test_mkdir_parents (main.PathTest)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1502, in test_mkdir_parents
    self.assertEqual(stat.S_IMODE(p.stat().st_mode), 0o555 & mode)
AssertionError: 511 != 365

======================================================================
FAIL: test_mkdir_parents (main.WindowsPathTest)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1502, in test_mkdir_parents
    self.assertEqual(stat.S_IMODE(p.stat().st_mode), 0o555 & mode)
AssertionError: 511 != 365

Ran 326 tests in 3.293s

FAILED (failures=2, skipped=90)

This line is problematic.
self.assertEqual(stat.S_IMODE(p.stat().st_mode), 0o555 & mode)

From http://docs.python.org/2/library/os.html#os.chmod:

Note
Although Windows supports chmod(), you can only set the file’s read-only flag with it (via the stat.S_IWRITE and stat.S_IREAD constants or a corresponding integer value). All other bits are ignored.

In Django, we skip chmod test on Windows.
https://github.com/django/django/blob/master/tests/staticfiles_tests/tests.py#L830

But this line is okay:
self.assertEqual(stat.S_IMODE(p.parent.stat().st_mode), mode)

So we should just skip that particular problematic line on Windows.

Thank you Vajrasky. Now this check is skipped on Windows.

Note that the description of the POSIX mkdir utility (*) has something a bit more complex to say about the -p option. Instead of simply applying the default umask, it computes """(S_IWUSR|S_IXUSR|~filemask)&0777 as the mode argument, where filemask is the file mode creation mask of the process (see XSH umask)""".

But unless the umask has a pathological value (such as 0o333), it doesn't really matter. The main point is that the original mode argument is ignored.

(*) http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

New changeset 87b81b7df7f0 by Antoine Pitrou in branch 'default':
Issue bpo-19921: When Path.mkdir() is called with parents=True, any missing parent is created with the default permissions, ignoring the mode argument (mimicking the POSIX "mkdir -p" command).
http://hg.python.org/cpython/rev/87b81b7df7f0