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] |
On Dec 16 13:36, Wayne Davison wrote: > On Sun, Dec 16, 2018 at 12:29 PM Corinna Vinschen wrote: > > In contrast to Linux the symlinks are not just faked symlinks with the underlying OS having direct access to the file descriptors. > > Yeah, Linux is more like a fuse where the open filehandles are used > directly on open, and the stat calls return pretend symlinks with the > lsof info. > > > The way it's implemented in Cygwin uses the actual file path resolution and then either works or fails as above. > > If Cygwin can't be changed into a fuse idiom, perhaps a hard-link > idiom could be used? For instance, when the /proc/$PID/fd/0 symlink is > being created, the code could try to hard-link the file to > /proc/$PID/.fd/0 first Nice try, but hardlinks don't cross FS borders. /proc is a filesystem on its own with its own inode numbers. 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... 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] |