[Patch] To handle Win32 pipe names
Fri Jun 18 01:22:00 GMT 2004
Sorry for the tardiness of this reply -
>From: Corinna Vinschen
>On May 21 13:37, Stephen Cleary wrote:
> > But, while //server/pipe/name may be a UNC path, it is not a path to a
> > file. And certain Win32 functions (including GetFileAttributes) do not
> > on those paths. When I say "do not work", I mean the Win32 SDK actually
> > says not to call them on those paths, and when I do it on my XP Pro SP1
> > (with all updates), odd behavior ensues. This is undefined behavior.
> > Sometimes I can see weird stuff at the filesystem level using
> > FileMon.
> > So, as it currently stands, stat() and the check for symlinks are fully
> > broken for Win32 pipes - they actually cause undefined behavior.
>Shouldn't Pierre's observations from yesterday clear this up a bit?
>Are the attributes set to 0x20 or -1 respectively?
Not necessarily. GetFileAttributes behavior is not defined for pipe paths.
So it cannot be called on those paths. I believe it returns -1 on my XP
system - after it opens and closes the pipe, changing the semantics for the
server! But there's no guarantee what it would return on other systems.
What we're up against here is a failing of the Win32 API:
1) GetFileAttributes cannot be called on a pipe path.
2) There is no function that can tell you that a path is a pipe path unless
you actually open it and use GetFileType - which changes server semantics.
3) Therefore, you have to detect pipe paths and avoid calling
>Yes, that's right. However, what I'm trying to say is this: Getting
>Win32 pipes working "untranslated" is not exactly what Cygwin's main
>job is. It's enough if open/read/write/close work. Stat doesn't
>necessarily need to return something meaningful. Actually a native
>Win32 named pipe isn't a POSIX named pipe. If stat returns that info
>for a Win32 named pipe, it would even be misleading, since the behaviour
>isn't POSIX like. But that's what a POSIX application would expect from
>such a named pipe.
The problem with not at least somewhat supporting stat is that all of the
common GNU command-line utilities (cat, etc.) have special code that depends
on stat to check for multiple input files referencing the same physical
The behavior of one end of the pipe is close enough. The main differences
between Win32 pipes and POSIX pipes is how they're created and how the
different ends interact together (POSIX pipes blocking on open). But if an
application is just using one end of a pipe (i.e., it was passed a pipe name
as a file name), the behavior between Win32 pipes and POSIX pipes should be
close enough to work. At least, I don't know of a way an application would
MSN 9 Dial-up Internet Access fights spam and pop-ups Â now 3 months FREE!
More information about the Cygwin-patches