Re: [Patch] To handle Win32 pipe names

[Corinna Vinschen <vinschen at redhat dot com>]

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 work 
> 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 SysInternals' 
> 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?

> "\\.\" doesn't necessarily mean "open a device". It is possible to open a 
> normal file using that syntax - "\\.\c:\tmp.txt" works fine. "\\.\" is just 
> a placeholder for "\??\" when the call goes to the native level.

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Co-Project Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.