Mail Archives: cygwin-developers/2001/03/27/09:41:11
----- Original Message -----
From: "Egor Duda" <deo AT logos-m DOT ru>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: "Egor Duda" <cygwin-developers AT cygwin DOT com>
Sent: Wednesday, March 28, 2001 12:21 AM
Subject: Re: whats a good magic number for fifo's?
> 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.
>
Sorry, yes I did sortof misinterpret your suggestion - I'm a little
tired right now :]. My point still stands - the ln command is a verrry
small wrapper around the cygwin symlink code. I wouldn't want to copy
that code, rather call it to create the symlink - thus the symlink
creation failing is an issue.
> 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'.
It's not quite that simple. We have to get into the fifo handling code
somewhere. That means that we cannot use any of the existing file
handling classes (because by that point we've already returnd a handle.
The symlink suggestion will work, because symlinks are checked as part
of path expansion. One actual issue is the case when a user creates
/dev/fifo, that file will never be readable.
Anyway, it's a moot point as I have implemented a very small and fast
magic number checker for files that are exactly x bytes in length. Thus
for most files the over head will be a call to createfile,
getfileattributes,getfilesize,closehandle. And all of that should be
cached by the os or network layer. I'm happy to go back and convert to
symlinks - once the meat of the thing is working.
> 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.
Ah. I'm of two minds on this: there seems to be a perception that
"cygwin1.dll" is a bad thing to link applications with. That it's an
"emulator" or "unneeded layer". Now I believe that putting all your
compatability headaches in one place and tuning that place to be very
fast is the best way to go - did I just describe cygwin1.dll?... but not
everyone does.
Rob
> 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 -