Mail Archives: cygwin-developers/2001/03/27/09:22:24
Hi!
Tuesday, 27 March, 2001 Robert Collins robert DOT collins AT itdomain DOT com DOT au wrote:
>> how about using symlinks pointing to some special destination (for
>> example to '/cygdrive/fifo')? all we need to do in this case is to
>> slightly modify current symlink resolution code.
RC> Lets see if it passes the "poke holes in the idea test"
RC> because it doesn't work with todays code (using /dev/clipboard as an
RC> existing example):
RC> administrator AT LIFELESSWKS /dev
RC> $ ls
RC> administrator AT LIFELESSWKS /dev
RC> $ ls -s /dev/clipboard myclip
RC> ls: myclip: No such file or directory
RC> 0 /dev/clipboard
i'm not sure i see what do you mean here. should it read 'ln -s' ?
if so, you've probably misunderstood me. i don't suggest creating
fifos with 'ln -s'. they should be created with mknod of mkfifo, just
like unix ones. what i do suggest, that under the hood, hidden from
user, mknod or mkfifo may create file whose contents are identical to
cygwin symlink pointing to /cygdrive/fifo.
at this point fifo-handling code shouldn't worry, whether this symlink
is created as shortcut or old style "!<symlink>" file, all it have to
to is to call readlink() and to see, whether result is
'/cygdrive/fifo'.
RC> On the other hand there are questions about users modifying the
RC> shortcut, windows link tracking manager, and the time it takes to
RC> resolve the shortcut (vs checking it's exactly 3 bytes long and reading
RC> the special). note: I don't know the answers to these potential issues.
all this issues are not fifo-specific. they apply to _any_ cygwin
symlink, and recent experiences show that current symlink
implementation is doing quite well.
RC> Finally, if we want to do an external interoperable (via a new .lib ?)
RC> fifo implementation
i don't think this is a goal worth achieving. making non-cygwin apps
to understand cygwin-specific features by linking them with some lib
is, i believe, a bad practice. creating such lib we'll bound ourselves
to some current implementation of this particular feature.
If some application wants to use cygwin mounts, cygwin symlinks, cygwin
ttys, it should be linked with cygwin1.dll
RC> (it'd be neat to have mingw interoperate with this fir example)
RC> then shortcuts may not be the best way. (We've got two shortcut
RC> formats in cygwin - if a user is running the old form, then that
RC> code has to be exported as well.)
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -