This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux


On Dec 17 10:25, Corinna Vinschen wrote:
> On Dec 17 05:30, Houder wrote:
> > On 2018-12-16 22:55, Corinna Vinschen wrote:
> > [snip]
> > 
> > > I'm mulling over adding some hack to open().  It could try to recognize
> > > the special case of opening a processes' own descriptor symlink within
> > > /proc and then warp the open() call into dup().  No idea how tricky
> > > or even feasible that is, though...
> > 
> > That is why I wrote the following in my STC:
> > 
> >         // Q: does Cygwin attempt to read the /tmp directory? (an attempt
> > that
> >         //    will fail, because the file has been unlinked)
> >         // it appears that reading a symlnk in /dev/fd can best be diverted
> > to
> >         // the open file descriptor of the process ...
> > 
> > What I meant was, that I see no reason to modify the symlink in this
> > special case, but in stead of that to access the file using fd N, where
> > N is equal to the one in /dev/fd/N.
> > 
> > File descriptor N has been left open by bash and should not have been
> > closed as result of the exec ...
> 
> tl;dr:
> 
>   cat tries to open /dev/fd/0.  /dev/fd/0 refers to a non-existing
>   file and that's why open fails.  Cygwin doesn't have special code to
>   handle the fd symlinks as refference to an actually open descriptors.
> 
> The long story:
> 
>   The descriptor hasn't been closed.  Cat still has the file open as fd 0.
> 
>   The problem is that you tell cat to open and read from /dev/fd/0,
>   *not* from fd 0.  That's quite a difference.  /dev/fd/0 is just some
>   arbitrary file which is given to open(2), a symlink at that.  First
>   thing open(2) does is to call the symlink evaluation code.  The
>   symlink is ultimately evaluated to the filename opened by the shell.

I just tested this on Linux.  Basically, open(2) in Cygwin is equivalent
to calling readlink(2); open(2):

  readlink(incoming_filename, resolved_filename, ...);
  open (resolved_filename, ...);

If I do this on Linux with a cat-clone calling readlink before calling
open, the error returned by open(2) is the same as on Cygwin, ENOENT.

The tricky part is to find out when resolving the filename is not
required because we already have a descriptor / HANDLE and how to
proceed from there...


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]