> That's not what I'm seeing when I run your test program on Linux: > > $ ./sun > fstat mode = 140666 > stat mode = 140777
True, but it creates the socket file with exactly how umask(0) told it to, and stat() shows that. So yeah, I should retract that it works on Linux with fchmod() -- on Linux the fchmod() call won't be at all necessary. And I just checked BSD and MacOS, too. [Truly, it's an old code that used to work everywhere but failed on Cygwin -- that's how I noticed, so I assumed it was because of fchmod() -- but it actually because of umask(0).] On Cygwin, however, I have to resort to good old chmod(). > Which is not necessarily related to the permissions on the file. Windows > socket is an in-memory object, the file is used merely for naming purposes. Sockets are in-memory objects everywhere. The UNIX socket file is a just connection "point" (much like devices and other special files) that has to have proper permissions for an accessor to be able to connect / read / etc. The permissions are checked first, then everything else goes. So if a socket file in the filesystem isn't "readable" for your permission category, you won't be able to connect regardless of what the in-memory things are, IIRC. > "Works", all right. But HOW does it works? Aren't the permissions seen on the > socket file merely a coincidence/convenience? No, they are NOT. They are actually granting / denying the access. Anyways, I think that I know how to fix this. As to whether or not Cygwin must be brought in line with Linux -- I can't tell, because I don't have files with ACLs on Linux, so I can't see how umask(0), when ignored, would screw permissions there... Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
