Re: [PATCH] cifs: Fix support for creating SFU socket

WSL does not use "LnxSOCK". This looks like an AI hallucination.

WSL stores data in NTFS reparse points:
 IO_REPARSE_TAG_AF_UNIX    - 0x80000023
 IO_REPARSE_TAG_LX_FIFO    - 0x80000024
 IO_REPARSE_TAG_LX_CHR     - 0x80000025
 IO_REPARSE_TAG_LX_BLK     - 0x80000026
 IO_REPARSE_TAG_LX_SYMLINK - 0xA000001D
And also in NTFS EAs:
 "$LXUID"
 "$LXGID"
 "$LXMOD"
 "$LXDEV"

All tests which I have done with WSL's DrvFs resulted in above reparse
points (or in native Windows symlinks).

Some sources which confirms those my testing:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
https://learn.microsoft.com/en-us/windows/wsl/file-permissions

WSL does not recognize "-o sfu" things at all.

So here I bet that AI "mixed" SFU and WSL formats and parts together and
created that hallucinated answer.

On Wednesday 08 July 2026 08:51:40 Steve French wrote:
> AI query made it sound like "LnxSOCK" is still used by WSL.  Is this
> change safe?
> 
> "Yes. WSL (particularly WSL 1 and WSL 2 when interacting with NTFS via
> DrvFs) uses the Lnx* metadata family to represent Linux special file
> types, including:
> 
> LnxSOCK
> LnxFIFO
> LnxCHR
> LnxBLK"
> 
> On Tue, Jul 7, 2026 at 4:13 AM Pali Rohár <[email protected]> wrote:
> >
> > SFU sockets are natively supported by Interix 3.0 subsystem and also by
> > later versions. It is part of Microsoft SFU (Windows Services for UNIX) and
> > Microsoft SUA (Subsystem for UNIX-based Applications). They can be created
> > and existing (stored on local disk or remote SMB share) can be recognized.
> >
> > SFU sockets are recognized also by NFS server included in Windows Server.
> > Windows NFS server versions since Windows Server 2012 uses new reparse
> > point format for storing new sockets, but still can recognize this old
> > format (also in the latest Windows Server 2022 version).
> >
> > SFU-style socket is a regular file which has system attribute set and
> > content of the file is one zero byte.
> >
> > These SFU-style sockets are already recognized by Linux SMB client.
> >
> > But Linux SMB client is currently creating new SFU socket in different
> > format which is not compatible with all those SFU applications. Fix this by
> > creating new sockets in correct SFU format which would be recognized by all
> > SFU, SUA, NFS and existing Linux SMB clients.
> >
> > This change affects only creating new sockets when mount option -o sfu is used.
> >
> > Signed-off-by: Pali Rohár <[email protected]>
> > ---
> >  fs/smb/client/smb2ops.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> > index 4f7eefa7a683..e59fda1b2230 100644
> > --- a/fs/smb/client/smb2ops.c
> > +++ b/fs/smb/client/smb2ops.c
> > @@ -5288,10 +5288,9 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
> >                 data = (u8 *)symname_utf16;
> >                 break;
> >         case S_IFSOCK:
> > -               type_len = 8;
> > -               strscpy(type, "LnxSOCK");
> > -               data = (u8 *)&pdev;
> > -               data_len = sizeof(pdev);
> > +               /* SFU socket is system file with one zero byte */
> > +               type_len = 1;
> > +               type[0] = '\0';
> >                 break;
> >         case S_IFIFO:
> >                 type_len = 8;
> > --
> > 2.20.1
> >
> >
> 
> 
> -- 
> Thanks,
> 
> Steve