This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 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?
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |