fstat and similar methods in fhandler_socket_local and fhandler_socket_unix

[Ken Brown]

On 2/24/2021 12:06 PM, Corinna Vinschen via Cygwin-developers wrote:
> On Feb 24 10:32, Ken Brown via Cygwin-developers wrote:
>> On 2/24/2021 4:06 AM, Corinna Vinschen via Cygwin-developers wrote:
>>> On Feb 22 15:01, Ken Brown via Cygwin-developers wrote:
>>>> OK, I've got patches ready to go for fstat, fstatvfs, fchmod, fchown, facl,
>>>> and link.  I have to test them, and then I'll send them to cygwin-patches.
>>>> In the case of link, I think the only way an fhandler_socket's link method
>>>> can be called is through link(2) being called on a socket file.  So the
>>>> following should do the job:
>>>>
>>>> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
>>>> index 21e1df172..f4aa12956 100644
>>>> --- a/winsup/cygwin/fhandler.h
>>>> +++ b/winsup/cygwin/fhandler.h
>>>> @@ -611,7 +611,6 @@ class fhandler_socket: public fhandler_base
>>>>      int __reg1 fchmod (mode_t newmode);
>>>>      int __reg2 fchown (uid_t newuid, gid_t newgid);
>>>>      int __reg3 facl (int, int, struct acl *);
>>>> -  int __reg2 link (const char *);
>>>>      off_t lseek (off_t, int)
>>>>      {
>>>>        set_errno (ESPIPE);
>>>> diff --git a/winsup/cygwin/fhandler_socket.cc b/winsup/cygwin/fhandler_socket.cc
>>>> index f22412650..08870cc6b 100644
>>>> --- a/winsup/cygwin/fhandler_socket.cc
>>>> +++ b/winsup/cygwin/fhandler_socket.cc
>>>> @@ -357,9 +357,3 @@ fhandler_socket::facl (int cmd, int nentries, aclent_t *aclbufp)
>>>>      set_errno (EOPNOTSUPP);
>>>>      return -1;
>>>>    }
>>>> -
>>>> -int
>>>> -fhandler_socket::link (const char *newpath)
>>>> -{
>>>> -  return fhandler_base::link (newpath);
>>>> -}
>>>
>>> Hmm.  What about linkat (AT_EMPTY_PATH, socket, ...)?
>>>
>>> This could be called for inet sockets as well as unnamed or abstract
>>> unix sockets, in theory...
>>
>> Thanks, I missed that case.  So we do need fhandler_socket::link.  The only
>> question in my mind is what errno it should set.  I just tried the
>> following:
>> [...]
>> On Linux I get
>>
>>    linkat: Invalid cross-device link
>>
>> So I think fhandler_socket::link should fail with EXDEV.  Probably it should
>> continue to call fhandler_base::link, and the latter should fail with EXDEV
>> instead of EPERM.  Or is there some case where EPERM is more appropriate?
> 
> fhandler_base::link returns EPERM because that covers "filesystem does
> not support the creation of hard links", which is the most probable
> case.  If we want to return EXDEV by default, the non-disk_file error
> case will have to check if oldpath and newpath are on the same
> filesystem.  I wonder if this is really worth the effort.

Not if it's my effort.  So I guess I should just make fhandler_socket::link 
return EXDEV.

Ken