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. :)
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. -slow
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
