Re: BUG: SMB3.11 POSIX extensions: Absolute symlinks lose leading slash on creation

Can you give a full context of the issue/bug? Link would be enough.
I just did not caught from this description what is the issue.

On Saturday 27 June 2026 18:14:07 Steve French wrote:
> Yes - I have verified that it is the client code (so copying Paulo and
> Pali who did most of this code) that has the bug.   When the
> FSCTL_SET_REPARSE_POINT is sent by the client, the leading '/' is
> already stripped off.  This affects both reparse=nfs (default)
> and reparse=wsl.    I would recommend mounting instead with
> "mfsymlinks" (which is safer for most cases as well since the
> symlinks are not processed by the server for the "mfsymlinks" case).
> 
> Paulo and Pali,
> Any ideas about this bug with absolute pathnames in symlinks being
> broken with reparse points by stripping off the leading slash?
> 
> On Fri, Jun 26, 2026 at 1:15 PM Ralph Boehme <[email protected]> wrote:
> >
> > On 6/26/26 7:41 PM, Ralph Boehme wrote:
> > > Now that we store as empty file + xattr on the server, not real
> > > symlinks, this design decision might need to be revisited.
> > >
> > > I don't remember of the top of my head if this behaviour is implemented
> > > in the client or the server. Does anyone remember? I'd have to check.
> >
> > it's the client: in cifs_convert_path_to_utf16() it strips the leading
> > slash for the symlink target when called from create_native_symlink().
> >
> > As symlinks in SMB3 POSIX may be created any way the server thinks is
> > safe (Samba does file+xattr, it never creates real symlinks on the
> > server), so symlinks are just a client side thing and we should allow
> > creating absolute symlinks. POSIX allows it (and users use it), so we
> > should (safely) also allow it in SMB3 POSIX.
> 
> 
> 
> -- 
> Thanks,
> 
> Steve