On Sun, Sep 29, 2024 at 7:52 AM Ralph Boehme <slow@xxxxxxxxx> wrote: > > On 9/29/24 11:26 AM, Pali Rohár wrote: > > Hello Ralph, thank you for information. So in case Samba is not > > going to use IO_REPARSE_TAG_NFS as primary way to serve special > > files, then it still makes sense to do this structure rename with my > > patch? > > that's up to Paulo and Steve. I can only talk protocol/spec and server. :) I don't think renaming that struct helps since to various servers we will have to use reparse points to save special files, and could be confusing to keep mentioning "nfs" for use cases in the client code where not really related much to NFS. > > Anyway, Windows clients mostly do not use IO_REPARSE_TAG_NFS. > > They don't *create* it, but they can *read* and present it. But I guess > that's what you meant. > > > From my knowledge on Windows this tag is used only by Windows NFS > > server. So scenario when Windows sends IO_REPARSE_TAG_NFS over SMB > > would be rare... It would be needed to export NFS share via Windows > > NFS server from SMB mount connected to Samba server. > > That's out of scope as far as SMB3 POSIX Extensions and I are concerned. :) > > > Note that Windows NFS client stores data about special files in EAs. > > So for example if you mount export from Linux NFS server by Windows > > NFS client, then NFS symlink would be visible to Windows > > applications as regular file with "NfsSymlinkTargetName" EA. More > > info is in this email: https://marc.info/?l=samba- > > technical&m=121423255119680 > > > > And this is what are Windows applications using if they want to > > access data of special files. So application access > > "NfsSymlinkTargetName" EA and not IO_REPARSE_TAG_NFS reparse tag. > > For symlinks SMB3 POSIX Extensions will use what Windows uses natively: > IO_REPARSE_TAG_SYMLINK. > > > To my knowledge neither Samba, nor Linux CIFS client supports > > "NfsSymlinkTargetName" EA for creating or parsing symlink. > > for Samba: yup. Yes. We would only want to support reading the NfsSymlinkTargetName for the rare cases where it would come up, but the default for creating symlinks on the client would be to use "mfysmlinks" (safer, client only symlinks, like Apple) when the mfsymlinks mount parm is specified, otherwise use the default Windows symlink type when creating a new (server side) symlink remotely. -- Thanks, Steve
