opendir(/dev/fd/n) should fail

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Jan 23 11:37:00 GMT 2015


On Jan 23 10:54, Helmut Karlowski wrote:
> 
> --------------------------------------------------
> Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> (23/01/2015 10:43)
> 
> > > numerous entries ...
> > 
> > This occurs on Linux as well, just with a few less entries in
> > fd (42 rather than 560).  These descriptors are apparently
> > created by bash for some reason I don't know, and our bash seems
> > to create some more descriptors than the newler bash on Linux.
> 
> It's not just bash. The same happens in my home-grown shell. Starting 
> with /dev/fd/3 opendir succeeds giving (only the opendir-entries):
> 
> [ 752:3] 
> globit:ksh_opendir:'/dev/fd/3/0/',prefix_len=12,hasdot=0,fignore=484444:''
> [ 752:3] 
> globit:ksh_opendir:'/dev/fd/3/1/',prefix_len=12,hasdot=0,fignore=484444:''
> [...]

Does the above occur with the snapshot?  How can I reproduce it?

> Linux seems to have  has a similar bug.

Ok, in that case I lean back a bit.

But the above ksh output is weird if it occurs under the snapshot.  What
I did in Cygwin was to fix the tests for a valid path under /proc/$PID/fd.
The next path component must be a valid descriptor as returned by the
application $PID.  A trailing slash and more path components result in
replacing the path with the content of the symlink and the trailing path
compenents and restarting the path evaluation.  In my subsequent testing
I was unable to enter wrong paths, so the above surprises me a bit.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150123/f12dac6e/attachment.sig>


More information about the Cygwin mailing list