Re: cygwin 1.7 lock directory problem
On Aug 18 01:52, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 01:05:13PM +0800, Huang Bambo wrote: 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? 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
Re: cygwin 1.7 lock directory problem
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. -- WBR, Andrey Repin (anrdae...@freemail.ru) 18.08.2010, 14:27 Sorry for my terrible english... -- 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
Re: cygwin 1.7 lock directory problem
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
Re: cygwin 1.7 lock directory problem
On 08/18/2010 05:08 AM, Corinna Vinschen wrote: 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. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: cygwin 1.7 lock directory problem
2010/8/18 Eric Blake ebl...@redhat.com: On 08/18/2010 05:08 AM, Corinna Vinschen wrote: 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. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). Even in linux, you can't generate core file in virtual directory also, so just don't generate core file if you can't write at anywhere. -- 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
Re: cygwin 1.7 lock directory problem
On Wed, Aug 18, 2010 at 09:51:29PM +0800, Huang Bambo wrote: 2010/8/18 Eric Blake ebl...@redhat.com: On 08/18/2010 05:08 AM, Corinna Vinschen wrote: 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. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). Even in linux, you can't generate core file in virtual directory also, so just don't generate core file if you can't write at anywhere. Right. I don't think we need a fallback. How is this any different than what happens when you generate a core dump in linux in a read-only directory? cgf -- 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
Re: cygwin 1.7 lock directory problem
On Aug 18 10:07, Christopher Faylor wrote: On Wed, Aug 18, 2010 at 09:51:29PM +0800, Huang Bambo wrote: 2010/8/18 Eric Blake ebl...@redhat.com: On 08/18/2010 05:08 AM, Corinna Vinschen wrote: 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. Using / as the fallback during a virtual directory makes sense to me (there may be other permission problems if / is not writable by the current user, but a stack dump is a best effort attempt anyways). Even in linux, you can't generate core file in virtual directory also, so just don't generate core file if you can't write at anywhere. Right. I don't think we need a fallback. How is this any different than what happens when you generate a core dump in linux in a read-only directory? I just applied a matching patch. 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
cygwin 1.7 lock directory problem
cygwin version: 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin I don't know if this happen to previous version or not. If I first cd to a directory, for example /cygdriver/x then cd to a virtual directory, for example /proc the /cygdriver/x will be locked untile I change director to other non-virtual directory. Is this a bug or designed to do so? -- 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
Re: cygwin 1.7 lock directory problem
On 8/17/2010 10:44 PM, Huang Bambo wrote: cygwin version: 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin I don't know if this happen to previous version or not. If I first cd to a directory, for example /cygdriver/x then cd to a virtual directory, for example /proc the /cygdriver/x will be locked untile I change director to other non-virtual directory. Is this a bug or designed to do so? Do you have a series of steps that produces the problem you see? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: cygwin 1.7 lock directory problem
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. -- 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
Re: cygwin 1.7 lock directory problem
On Wed, Aug 18, 2010 at 01:05:13PM +0800, Huang Bambo wrote: 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. cygcheck output would have saved speculation on which version you're running. -- 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
