X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Wed, 18 Aug 2010 13:08:52 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: cygwin 1.7 lock directory problem Message-ID: <20100818110852.GS11340@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4C6B5191 DOT 7070602 AT cygwin DOT com> <20100818055204 DOT GA19288 AT ednor DOT casa DOT cgf DOT cx> <20100818085754 DOT GP11340 AT calimero DOT vinschen DOT de> <445852471 DOT 20100818142802 AT mtu-net DOT ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <445852471.20100818142802@mtu-net.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Aug 18 14:28, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> >>Do you have a series of steps that produces the problem you see? > >> >> > >> > > >> >As I said in previous mail. > >> >1. cd /cygdriver/i ( I is mounted as a usb-stick) > >> >2. cd /proc 3. Use some tools such as Unlocker to check driver I, > >> >Unlocker said driver I is locked by bash. > >> >4. cd / ( / is at d:\cygwin ) > >> >5. do the same as step 3, driver is not locked by bash. > >> > >> That's how Cygwin 1.7.5 would work. I would expect different behavior > >> for 1.7.6. > > > No, that's also how 1.7.6 works. I documented this behaviour in > > path.cc: > > > /* Note that we don't set the dir handle to NULL for virtual paths. > > The handle is used to generate a stackdump file. Since we can't > > create a stackdump in a virtual path, we have at least *some* > > directory handle to generate the stackdump in. > > > However, note that we have to make sure that we don't use the handle > > wrongly as soon as we start to use it in other cases as well. */ > > > Looks like this behaviour is a problem and we should better close the > > old handle. What to do with the new one? Just set it to NULL and > > disallow stackdumps as long as we're in a virtual path? Or set it to > > some well known path, like Cygwin's root? > > /var or /tmp would be more sensible. Maybe, but it also costs time. /var and /tmp Windows paths have to be generated by a full path conversion every time you call chdir() to a virtual directory. The Cygwin installation path (aka the root dir) is just available. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple