Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.007 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; '(even': 0.05; 'intermediate': 0.07; 'socket': 0.07; 'subject:skip:s 10': 0.07; 'finished.': 0.09; 'pointers': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'afterwards.': 0.16; 'deletion': 0.16; 'hmm.': 0.16; 'lie': 0.16; 'mkdir': 0.16; 'runs,': 0.16; 'silly': 0.16; 'subject:issue': 0.16; 'subject:timing': 0.16; 'appropriate': 0.16; 'wrote:': 0.18; 'connects': 0.19; 'hacking': 0.19; 'seems': 0.21; 'machine': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'cc:2**0': 0.24; 'cc:no real name:2**0': 0.24; 'script': 0.25; '>': 0.26; 'mention': 0.26; 'header:In-Reply-To:1': 0.27; 'tim': 0.29; 'message- id:@mail.gmail.com': 0.30; "i'm": 0.30; 'block,': 0.31; 'though.': 0.31; 'file': 0.32; 'run': 0.32; 'quite': 0.32; 'linux': 0.33; 'running': 0.33; 'not.': 0.33; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'event,': 0.36; 'executing': 0.36; 'done': 0.36; 'so,': 0.37; 'remote': 0.38; 'pm,': 0.38; 'does': 0.39; "couldn't": 0.39; 'though,': 0.39; 'even': 0.60; 'tell': 0.60; 'from:charset:utf-8': 0.61; 'kind': 0.63; 'more': 0.64; '30,': 0.65; 'to:addr:gmail.com': 0.65; 'sound': 0.68; 'jul': 0.74; 'deleted?': 0.84; 'procedure,': 0.84; 'approach.': 0.91; 'thing,': 0.91; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zx01JX/2ZqenHIjNnZLCz0f/cVkZaNkW107loganOP0=; b=cOalQZvT0OThAdUYxc4cXKK6ZEO99PW+Tls8oPgB5UMm/8ih/8OWZuPaW9Mi7E/IVB 2J9k5kTEC9+jGED7yrjuVKUkxxX2td6g3Xcw9+6CTf6DsRvnMSRxucrNioesDWIi3DpR 8N2H3zBu7N/udKJTGpxarJMxzzl/U6FLiIssMTe1eNRzdhi800ErVkaZpZ2Oiq+zm0ei zf2Tlqg6b7YHXXNZBJfQbEVv2EC3ViCp2kVnEjVP3Mk8wE2e2sWklGCK+8pM4CXpXR9z zOmby/vRGS/XemAhYSmEA2xv63ueiTaubZnjwPJe5ZqPRdcG6B4ZrSDY8VR9Q5C8WYrj YIlw== MIME-Version: 1.0 X-Received: by 10.43.141.206 with SMTP id jf14mr22600555icc.8.1375204151166; Tue, 30 Jul 2013 10:09:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 20:09:11 +0300 Subject: Re: timing issue: shutil.rmtree and os.makedirs From: =?UTF-8?B?R8O2a3R1xJ8gS2F5YWFscA==?= To: Chris Angelico Content-Type: multipart/alternative; boundary=001a11c2d478ec907e04e2bdaa71 Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 75 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1375204161 news.xs4all.nl 15933 [2001:888:2000:d::a6]:40484 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:51585 --001a11c2d478ec907e04e2bdaa71 Content-Type: text/plain; charset=UTF-8 On Jul 30, 2013 3:29 PM, "Chris Angelico" wrote: > > On Tue, Jul 30, 2013 at 2:10 PM, Tim wrote: > > hmm, now that you mention it, this is executing on a remote box with access to the same file system my local calling program is on. That is, there is a local call to an intermediate script that connects to a socket on the remote where the above program actually runs, but the file system is the same place for both local and remote. > > > > But even so, since the script that does the rmtree and mkdir is running on the same machine (even though it's remote), I would think the mkdir couldn't execute until the rmtree was completely finished. > > Hmm. What system is used for the file system sharing? I know quite a > few of them lie about whether something's been completely done or not. > > Can you use inotify to tell you when the directory's been deleted? > Seems stupid though. Inotify is a linux thing, but there is kqueue for Free?BSD. OP can run the deletion procedure, wait for a NOTE_DELETE event, which would block, and create the fresh directory afterwards. It may require some C hacking though, in case Python lacks a kqueue wrapper. I think that this kind of approach would be more sound than a check-wait-loop approach. (I would elaborate more with pointers to appropriate documentation, but I'm on a silly tablet, please excuse me for that.) -gk --001a11c2d478ec907e04e2bdaa71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 30, 2013 3:29 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Tue, Jul 30, 2013 at 2:10 PM, Tim <jtim.arnold@gmail.com> wrote:
> > hmm, now that you mention it, this is executing on a remote box w= ith access to the same file system my local calling program is on. That is,= there is a local call to an intermediate script that connects to a socket = on the remote where the above program actually runs, but the file system is= the same place for both local and remote.
> >
> > But even so, since the script that does the rmtree and mkdir is r= unning on the same machine (even though it's remote), I would think the= mkdir couldn't execute until the rmtree was completely finished.
>
> Hmm. What system is used for the file system sharing? I know quite a > few of them lie about whether something's been completely done or = not.
>
> Can you use inotify to tell you when the directory's been deleted?=
> Seems stupid though.

Inotify is a linux thing, but there is kqueue for Free?BSD.=C2=A0 OP can= run the deletion procedure, wait for a NOTE_DELETE event, which would bloc= k, and create the fresh directory afterwards.=C2=A0 It may require some C h= acking though, in case Python lacks a kqueue wrapper.=C2=A0 I think that th= is kind of approach would be more sound than a check-wait-loop approach.

(I would elaborate more with pointers to appropriate documentation, but = I'm on a silly tablet, please excuse me for that.)

-gk

--001a11c2d478ec907e04e2bdaa71--