From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15161 invoked from network); 23 Mar 2009 15:43:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 23 Mar 2009 15:43:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 64202 invoked from network); 23 Mar 2009 15:43:14 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 23 Mar 2009 15:43:14 -0000 Received: (qmail 13348 invoked by alias); 23 Mar 2009 15:43:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26771 Received: (qmail 13335 invoked from network); 23 Mar 2009 15:43:08 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 23 Mar 2009 15:43:08 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [208.87.233.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 6ECE880EA0C1 for ; Mon, 23 Mar 2009 16:43:05 +0100 (CET) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly25g.srv.mailcontrol.com (MailControl) with ESMTP id n2NFgoQZ007736 for ; Mon, 23 Mar 2009 15:43:01 GMT Received: from news01.csr.com ([10.99.50.25]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 15:39:26 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id n2NFdQwx005224 for ; Mon, 23 Mar 2009 15:39:26 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id n2NFdQom005220 for ; Mon, 23 Mar 2009 15:39:26 GMT Message-Id: <200903231539.n2NFdQom005220@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers Subject: Re: cd -s symlink hangs (sometimes?) In-reply-to: <090323081809.ZM4297@torch.brasslantern.com> References: <237967ef0903201412h2a7b99c9ya5101509a3972313@mail.gmail.com> <20090320224856.73dae001@pws-pc> <237967ef0903201615x72769fe4va86273c3fa07cb2e@mail.gmail.com> <20090322125410.66a9d294@pws-pc> <090323081809.ZM4297@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Mon, 23 Mar 2009 08:18:09 -0700." Date: Mon, 23 Mar 2009 15:39:26 +0000 From: Peter Stephenson X-OriginalArrivalTime: 23 Mar 2009 15:39:26.0045 (UTC) FILETIME=[8BE4E8D0:01C9ABCD] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.71.0.135 X-Virus-Scanned: ClamAV 0.92.1/9152/Mon Mar 23 14:15:24 2009 on bifrost X-Virus-Status: Clean Bart Schaefer wrote: > Anyway, as best I can tell the reason for the open("..") is to cause > an error to be returned from restoredir() later. At the code above, > if open(".") fails but zgetdir() succeeds, we can stat(".") but not > read it. So the code attempts to arrange that restoredir() will cd > into a directory that we CAN read (".." in this case) I don't think that's likely to work anyway, though... if we can't open(".") because of *directory* permissions, that means we won't be able to open("..") either. They're both just entries in the current directory (that happen to have special meanings). (It's because we can only track up the hard-linked layout by laboriously opening the file ".." in the current directory that it's all so complicated.) > but leaves > mismatched ino,dev information in the dirsave struct so restoredir() > will return nonzero, causing lchdir() to return -2. Presumably with similar effects to what we're seeing now, i.e. mismatched diretories. Sounds like another good reason for completely rewriting the ("..") thing. > In the course of looking at this I think I've spotted another problem, > which possibly only affects filesystems where a double slash at the > root means something different (mainly Cygwin at this point). Have a > look at zchdir() and consider the consequences of passing it a file > name consisting entirely of "/" characters repeated PATH_MAX+N times. So if the initial chdir() fails, shouldn't we rewind the pointer to the start (dir), then break out of the loop and return failure? Or what else? -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070