Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!194.109.133.83.MISMATCH!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <fd605b09-ce7d-4c33-922d-57f423a09556@googlegroups.com>
References: <fd605b09-ce7d-4c33-922d-57f423a09556@googlegroups.com>
Date: Tue, 30 Jul 2013 00:52:36 +0100
Subject: Re: timing issue: shutil.rmtree and os.makedirs
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5292.1375141959.3114.python-list@python.org>
Lines: 38
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:51527

On Mon, Jul 29, 2013 at 8:16 PM, Tim <jtim.arnold@gmail.com> wrote:
> My intent is to pass it a directory name or path and if it exists, use shutil.rmtree to remove whatever is there (if it isn't a directory, try to unlink it); then use os.makedirs to create a new directory or path:
>
> def make_clean_dir(directory):
>     if os.path.exists(directory):
>         if os.path.isdir(directory):
>             shutil.rmtree(directory)
>         else:
>             os.unlink(directory)
>     os.makedirs(directory)
>
> The last bit of the traceback is:
> File "/develop/myproject/helpers/__init__.py", line 35, in make_clean_dir
>     os.makedirs(directory)
>   File "/usr/local/lib/python2.7/os.py", line 157, in makedirs
>     mkdir(name, mode)
> OSError: [Errno 17] File exists: '/users/tim/testing/testing_html'
>
> The directory 'testing_html' existed when I executed the function;

First thing I'd check is: Did rmtree succeed? Try removing the
makedirs and test it again; then, when your process has completely
finished, see if the directory is there. If it is, the problem is in
rmtree - for instance:

* You might not have permission to remove everything
* There might be a messed-up object in the file system
* If the directory is a remote share mount point, the other end might
have lied about the removal
* Something might have been created inside the directory during the removal
* Myriad other possibilities

As I understand rmtree's docs, any errors *that it detects* will be
raised as exceptions (since you haven't told it to suppress or handle
them), but possibly there's an error that it isn't able to detect.
Worth a test, anyhow.

ChrisA