Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux
- Date: Wed, 02 Jan 2019 14:56:45 +0100
- From: Houder <houder@xxxxxxxxx>
- Subject: Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux
On 2018-12-17 12:26, Corinna Vinschen wrote:
On Dec 17 10:25, Corinna Vinschen wrote:
On Dec 17 05:30, Houder wrote:
> On 2018-12-16 22:55, Corinna Vinschen wrote:
> > 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
> // will fail, because the file has been unlinked)
> // it appears that reading a symlnk in /dev/fd can best be diverted
> // 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 ...
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...
( /dev/fd/N not synonymous with file descriptor N; it is on Linux )
For the record only:
You were/are right and I was complete wrong: open file descriptor N is
only by chance equal to /dev/fd/N ...
Neither the semantics of FreeBSD (and Solaris) -- similar to dup() --
nor those of Linux (where the opening of the deleted file results in a
new entry in the open file table) are feasible in Cygwin.
FreeBSD (Solaris) and Linux require the concept of a "directory cache"
to exist in order to make the above possible (that cache must also be
exposed to the user in some way).
FreeBSD (Solaris): based on the filename, the corresponding open file
descriptION is found; a new file descriptor to this entry in the open
file table is returned to the user ...
It appears as if the inherited open file descriptor is dup'ed, but it
Linux: based on the filename, the corresponding inode is found; a new
entry in the open file table is created; a file descriptor to the new
entry in the open file table is returned to the user ...
(this can be verified using kcmp(2) ).
The above is not possible in Cygwin. Cygwin cannot follow here.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple