[Patch] To handle Win32 pipe names

Stephen Cleary yjfwhhvvvhzk6wdy@hotmail.com
Fri May 21 17:37:00 GMT 2004

Some comments are inline.

>From: Corinna Vinschen
>Subject: Re: [Patch] To handle Win32 pipe names
>Date: Wed, 19 May 2004 10:52:37 +0200
>On May 17 12:57, Stephen Cleary wrote:
> > Attached is a patch against the current CVS sources, with a ChangeLog. 
> > patch allows Win32 pipe names to be opened as files.
>that's still not quite what I had in mind.  I'd like to see as less special
>windows path handling in Cygwin as possible.  A //foo/pipe/whatever path is
>just like any other UNC path and could be handled as such, no extra code
>should be necessary.  //./pipe/whatever should also go through without any
>extra code so the whole idea would be to do exactly nothing, except the
>existing code has a bug, of course.  I really don't care for stat.  If
>Windows named pipes are recognized as files, so be it.

I agree that as few as possible changes should be made to support named 
pipes, with the smallest amount of Win32 path stuff gunking up the works...

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.

>I've just quickly stepped through the existing code and it looks like
>\\.\foo paths can be opened normally on NT.  Just stat seems to have
>a problem, since stat_worker checks for fh->exists() at one point and
>GetFileAttributes returned INVALID_FILE_ATTRIBUTES on devices.  So that
>explains your patch to symlink_info::check.  But it's not exactly right
>to circumvent this only for pipes.  Any \\.\foo path should get the
>same handling.  Wouldn't it be more straightforward to use is_unc_share
>or a slightly modified version of is_unc_share?

"\\.\" 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.

But we could just treat any path starting with "\\.\" as a device, if you 
really want to. I've never seen it actually used to open a regular disk 
file, so we'd probably get away with it.

Your thoughts?

Watch LIVE baseball games on your computer with MLB.TV, included with MSN 
Premium! http://join.msn.click-url.com/go/onm00200439ave/direct/01/

More information about the Cygwin-patches mailing list