Author jokoala
Recipients Arfrever, Laurent.Mazuel, belopolsky, docs@python, draghuram, eric.araujo, georg.brandl, ggenellina, giampaolo.rodola, ijmorlan, jokoala, r.david.murray, terry.reedy, ysj.ray, zooko
Date 2012-03-11.13:48:06
SpamBayes Score 8.61057e-08
Marked as misclassified No
Message-id <1331473688.21.0.868440735968.issue13498@psf.upfronthosting.co.za>
In-reply-to
Content
I want to mention a situation in which the current behaviour of os.makedirs is
confusing. At the first glance I would expect that if
>>> os.makedirs(path)
succeeds, then a following call to
>>> os.makedirs(path, exist_ok=True)
will succeed too.

This is not always the case. Consider this (assuming Linux as OS and the umask
set to 0o022):
>>> os.makedirs('/tmp/mytest')
>>> os.chmod('/tmp/mytest', 0o2755)
>>> path='/tmp/mytest/dir1'
>>> os.makedirs(path)
>>> os.makedirs(path, exist_ok=True)
OSError: [Errno 17] File exists: '/tmp/mytest/dir1'

The directory '/tmp/mytest' here has the SETGID flag set, which is inherited
automatically. Therefore the flags of '/tmp/mytest/dir1' are not 0o755 as expected by os.makedirs, but 0o2755.

The same problem occurs if the user can changes the umask between the calls to
os.makedirs.

I wonder in what situation the current behaviour of os.makedirs is really
helpful and not introducing subtle bugs. Consider using os.makedirs to ensure
that the output directory of your script exists. Now the user decides to make
this output directory world writeable. For most cases this is no problem, but
os.makedirs will complain.
History
Date User Action Args
2012-03-11 13:48:08jokoalasetrecipients: + jokoala, georg.brandl, terry.reedy, zooko, belopolsky, ggenellina, draghuram, giampaolo.rodola, ijmorlan, eric.araujo, Arfrever, r.david.murray, ysj.ray, docs@python, Laurent.Mazuel
2012-03-11 13:48:08jokoalasetmessageid: <1331473688.21.0.868440735968.issue13498@psf.upfronthosting.co.za>
2012-03-11 13:48:07jokoalalinkissue13498 messages
2012-03-11 13:48:07jokoalacreate