This function parses NFS-style reparse points, which are used only by
Windows NFS server since Windows Server 2012 version. This style of special
files is not understood by Microsoft POSIX / Interix / SFU / SUA subsystems.
So make it clear that parse_reparse_posix() function and reparse_posix_data
structure are not POSIX general, but rather NFS specific.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
fs/smb/client/cifsglob.h | 2 +-
fs/smb/client/cifspdu.h | 2 +-
fs/smb/client/reparse.c | 14 +++++++-------
fs/smb/client/reparse.h | 2 +-
fs/smb/common/smb2pdu.h | 2 +-
5 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/smb/client/cifsglob.h b/fs/smb/client/cifsglob.h
index 9eae8649f90c..119537e98f77 100644
--- a/fs/smb/client/cifsglob.h
+++ b/fs/smb/client/cifsglob.h
@@ -223,7 +223,7 @@ struct cifs_open_info_data {
__u32 tag;
union {
struct reparse_data_buffer *buf;
- struct reparse_posix_data *posix;
+ struct reparse_nfs_data *nfs;
};
} reparse;
struct {
diff --git a/fs/smb/client/cifspdu.h b/fs/smb/client/cifspdu.h
index c3b6263060b0..fefd7e5eb170 100644
--- a/fs/smb/client/cifspdu.h
+++ b/fs/smb/client/cifspdu.h
@@ -1506,7 +1506,7 @@ struct reparse_symlink_data {
#define NFS_SPECFILE_BLK 0x00000000004B4C42
#define NFS_SPECFILE_FIFO 0x000000004F464946
#define NFS_SPECFILE_SOCK 0x000000004B434F53
-struct reparse_posix_data {
+struct reparse_nfs_data {
__le32 ReparseTag;
__le16 ReparseDataLength;
__u16 Reserved;
diff --git a/fs/smb/client/reparse.c b/fs/smb/client/reparse.c
index 35e8f2e18530..a23ea2f78c09 100644
--- a/fs/smb/client/reparse.c
+++ b/fs/smb/client/reparse.c
@@ -81,7 +81,7 @@ int smb2_create_reparse_symlink(const unsigned int xid, struct inode *inode,
return rc;
}
-static int nfs_set_reparse_buf(struct reparse_posix_data *buf,
+static int nfs_set_reparse_buf(struct reparse_nfs_data *buf,
mode_t mode, dev_t dev,
struct kvec *iov)
{
@@ -120,20 +120,20 @@ static int mknod_nfs(unsigned int xid, struct inode *inode,
const char *full_path, umode_t mode, dev_t dev)
{
struct cifs_open_info_data data;
- struct reparse_posix_data *p;
+ struct reparse_nfs_data *p;
struct inode *new;
struct kvec iov;
__u8 buf[sizeof(*p) + sizeof(__le64)];
int rc;
- p = (struct reparse_posix_data *)buf;
+ p = (struct reparse_nfs_data *)buf;
rc = nfs_set_reparse_buf(p, mode, dev, &iov);
if (rc)
return rc;
data = (struct cifs_open_info_data) {
.reparse_point = true,
- .reparse = { .tag = IO_REPARSE_TAG_NFS, .posix = p, },
+ .reparse = { .tag = IO_REPARSE_TAG_NFS, .nfs = p, },
};
new = smb2_get_reparse_inode(&data, inode->i_sb, xid,
@@ -313,7 +313,7 @@ int smb2_mknod_reparse(unsigned int xid, struct inode *inode,
}
/* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */
-static int parse_reparse_posix(struct reparse_posix_data *buf,
+static int parse_reparse_nfs(struct reparse_nfs_data *buf,
struct cifs_sb_info *cifs_sb,
struct cifs_open_info_data *data)
{
@@ -414,7 +414,7 @@ int parse_reparse_point(struct reparse_data_buffer *buf,
/* See MS-FSCC 2.1.2 */
switch (le32_to_cpu(buf->ReparseTag)) {
case IO_REPARSE_TAG_NFS:
- return parse_reparse_posix((struct reparse_posix_data *)buf,
+ return parse_reparse_nfs((struct reparse_nfs_data *)buf,
cifs_sb, data);
case IO_REPARSE_TAG_SYMLINK:
return parse_reparse_symlink(
@@ -507,7 +507,7 @@ bool cifs_reparse_point_to_fattr(struct cifs_sb_info *cifs_sb,
struct cifs_fattr *fattr,
struct cifs_open_info_data *data)
{
- struct reparse_posix_data *buf = data->reparse.posix;
+ struct reparse_nfs_data *buf = data->reparse.nfs;
u32 tag = data->reparse.tag;
if (tag == IO_REPARSE_TAG_NFS && buf) {
diff --git a/fs/smb/client/reparse.h b/fs/smb/client/reparse.h
index 5be54878265e..2a91f64de557 100644
--- a/fs/smb/client/reparse.h
+++ b/fs/smb/client/reparse.h
@@ -18,7 +18,7 @@
*/
#define IO_REPARSE_TAG_INTERNAL ((__u32)~0U)
-static inline dev_t reparse_nfs_mkdev(struct reparse_posix_data *buf)
+static inline dev_t reparse_nfs_mkdev(struct reparse_nfs_data *buf)
{
u32 major, minor;
diff --git a/fs/smb/common/smb2pdu.h b/fs/smb/common/smb2pdu.h
index c769f9dbc0b4..0e77a4c0145a 100644
--- a/fs/smb/common/smb2pdu.h
+++ b/fs/smb/common/smb2pdu.h
@@ -1550,7 +1550,7 @@ struct reparse_symlink_data_buffer {
__u8 PathBuffer[]; /* Variable Length */
} __packed;
-/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_posix_data */
+/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_nfs_data */
struct validate_negotiate_info_req {
__le32 Capabilities;
--
2.20.1
since they are being used by default for servers supporting special files in the "SMB3.1.1 POSIX Extensions" ... it might be appropriate to keep a less confusing name ("NFS" for "SMB3.1.1 POSIX" could be confusing) On Sat, Sep 28, 2024 at 5:01 PM Pali Rohár <pali@kernel.org> wrote: > > This function parses NFS-style reparse points, which are used only by > Windows NFS server since Windows Server 2012 version. This style of special > files is not understood by Microsoft POSIX / Interix / SFU / SUA subsystems. > > So make it clear that parse_reparse_posix() function and reparse_posix_data > structure are not POSIX general, but rather NFS specific. > > Signed-off-by: Pali Rohár <pali@kernel.org> > --- > fs/smb/client/cifsglob.h | 2 +- > fs/smb/client/cifspdu.h | 2 +- > fs/smb/client/reparse.c | 14 +++++++------- > fs/smb/client/reparse.h | 2 +- > fs/smb/common/smb2pdu.h | 2 +- > 5 files changed, 11 insertions(+), 11 deletions(-) > > diff --git a/fs/smb/client/cifsglob.h b/fs/smb/client/cifsglob.h > index 9eae8649f90c..119537e98f77 100644 > --- a/fs/smb/client/cifsglob.h > +++ b/fs/smb/client/cifsglob.h > @@ -223,7 +223,7 @@ struct cifs_open_info_data { > __u32 tag; > union { > struct reparse_data_buffer *buf; > - struct reparse_posix_data *posix; > + struct reparse_nfs_data *nfs; > }; > } reparse; > struct { > diff --git a/fs/smb/client/cifspdu.h b/fs/smb/client/cifspdu.h > index c3b6263060b0..fefd7e5eb170 100644 > --- a/fs/smb/client/cifspdu.h > +++ b/fs/smb/client/cifspdu.h > @@ -1506,7 +1506,7 @@ struct reparse_symlink_data { > #define NFS_SPECFILE_BLK 0x00000000004B4C42 > #define NFS_SPECFILE_FIFO 0x000000004F464946 > #define NFS_SPECFILE_SOCK 0x000000004B434F53 > -struct reparse_posix_data { > +struct reparse_nfs_data { > __le32 ReparseTag; > __le16 ReparseDataLength; > __u16 Reserved; > diff --git a/fs/smb/client/reparse.c b/fs/smb/client/reparse.c > index 35e8f2e18530..a23ea2f78c09 100644 > --- a/fs/smb/client/reparse.c > +++ b/fs/smb/client/reparse.c > @@ -81,7 +81,7 @@ int smb2_create_reparse_symlink(const unsigned int xid, struct inode *inode, > return rc; > } > > -static int nfs_set_reparse_buf(struct reparse_posix_data *buf, > +static int nfs_set_reparse_buf(struct reparse_nfs_data *buf, > mode_t mode, dev_t dev, > struct kvec *iov) > { > @@ -120,20 +120,20 @@ static int mknod_nfs(unsigned int xid, struct inode *inode, > const char *full_path, umode_t mode, dev_t dev) > { > struct cifs_open_info_data data; > - struct reparse_posix_data *p; > + struct reparse_nfs_data *p; > struct inode *new; > struct kvec iov; > __u8 buf[sizeof(*p) + sizeof(__le64)]; > int rc; > > - p = (struct reparse_posix_data *)buf; > + p = (struct reparse_nfs_data *)buf; > rc = nfs_set_reparse_buf(p, mode, dev, &iov); > if (rc) > return rc; > > data = (struct cifs_open_info_data) { > .reparse_point = true, > - .reparse = { .tag = IO_REPARSE_TAG_NFS, .posix = p, }, > + .reparse = { .tag = IO_REPARSE_TAG_NFS, .nfs = p, }, > }; > > new = smb2_get_reparse_inode(&data, inode->i_sb, xid, > @@ -313,7 +313,7 @@ int smb2_mknod_reparse(unsigned int xid, struct inode *inode, > } > > /* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */ > -static int parse_reparse_posix(struct reparse_posix_data *buf, > +static int parse_reparse_nfs(struct reparse_nfs_data *buf, > struct cifs_sb_info *cifs_sb, > struct cifs_open_info_data *data) > { > @@ -414,7 +414,7 @@ int parse_reparse_point(struct reparse_data_buffer *buf, > /* See MS-FSCC 2.1.2 */ > switch (le32_to_cpu(buf->ReparseTag)) { > case IO_REPARSE_TAG_NFS: > - return parse_reparse_posix((struct reparse_posix_data *)buf, > + return parse_reparse_nfs((struct reparse_nfs_data *)buf, > cifs_sb, data); > case IO_REPARSE_TAG_SYMLINK: > return parse_reparse_symlink( > @@ -507,7 +507,7 @@ bool cifs_reparse_point_to_fattr(struct cifs_sb_info *cifs_sb, > struct cifs_fattr *fattr, > struct cifs_open_info_data *data) > { > - struct reparse_posix_data *buf = data->reparse.posix; > + struct reparse_nfs_data *buf = data->reparse.nfs; > u32 tag = data->reparse.tag; > > if (tag == IO_REPARSE_TAG_NFS && buf) { > diff --git a/fs/smb/client/reparse.h b/fs/smb/client/reparse.h > index 5be54878265e..2a91f64de557 100644 > --- a/fs/smb/client/reparse.h > +++ b/fs/smb/client/reparse.h > @@ -18,7 +18,7 @@ > */ > #define IO_REPARSE_TAG_INTERNAL ((__u32)~0U) > > -static inline dev_t reparse_nfs_mkdev(struct reparse_posix_data *buf) > +static inline dev_t reparse_nfs_mkdev(struct reparse_nfs_data *buf) > { > u32 major, minor; > > diff --git a/fs/smb/common/smb2pdu.h b/fs/smb/common/smb2pdu.h > index c769f9dbc0b4..0e77a4c0145a 100644 > --- a/fs/smb/common/smb2pdu.h > +++ b/fs/smb/common/smb2pdu.h > @@ -1550,7 +1550,7 @@ struct reparse_symlink_data_buffer { > __u8 PathBuffer[]; /* Variable Length */ > } __packed; > > -/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_posix_data */ > +/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_nfs_data */ > > struct validate_negotiate_info_req { > __le32 Capabilities; > -- > 2.20.1 > > -- Thanks, Steve
Keep in mind that the inode type info will also be available via the posix infolevel in the mode bits. The changes for Samba by Volker have already been merged last week. Spec draft: https://gitlab.com/samba-team/smb3-posix-spec/-/merge_requests/2 <https://www.samba.org/~slow/SMB3_POSIX/fscc_posix_extensions.html#posix-mode> Fwiw, in a future version of POSIX-FSA we will probably say that in POSIX mode (per handle) the POSIX client MUST use the POSIXMode field for the inode type and one MUST NOT use the NFS reparse point tag for this. The server in POSIX mode MAY also set the reparse tag, but that's still open to debate from my pov. The NFS reparse tag will be there basically for the Windows clients in non-POSIX mode and support will be mandatory in the server. The only reparse tag we'd in POSIX mode for inode type information would be IO_REPARSE_TAG_SYMLINK for symlinks. -slow On 9/29/24 6:57 AM, Steve French wrote: > since they are being used by default for servers supporting special > files in the "SMB3.1.1 POSIX Extensions" ... it might be appropriate > to keep a less confusing name ("NFS" for "SMB3.1.1 POSIX" could be > confusing) > > On Sat, Sep 28, 2024 at 5:01 PM Pali Rohár <pali@kernel.org> wrote: >> >> This function parses NFS-style reparse points, which are used only by >> Windows NFS server since Windows Server 2012 version. This style of special >> files is not understood by Microsoft POSIX / Interix / SFU / SUA subsystems. >> >> So make it clear that parse_reparse_posix() function and reparse_posix_data >> structure are not POSIX general, but rather NFS specific. >> >> Signed-off-by: Pali Rohár <pali@kernel.org> >> --- >> fs/smb/client/cifsglob.h | 2 +- >> fs/smb/client/cifspdu.h | 2 +- >> fs/smb/client/reparse.c | 14 +++++++------- >> fs/smb/client/reparse.h | 2 +- >> fs/smb/common/smb2pdu.h | 2 +- >> 5 files changed, 11 insertions(+), 11 deletions(-) >> >> diff --git a/fs/smb/client/cifsglob.h b/fs/smb/client/cifsglob.h >> index 9eae8649f90c..119537e98f77 100644 >> --- a/fs/smb/client/cifsglob.h >> +++ b/fs/smb/client/cifsglob.h >> @@ -223,7 +223,7 @@ struct cifs_open_info_data { >> __u32 tag; >> union { >> struct reparse_data_buffer *buf; >> - struct reparse_posix_data *posix; >> + struct reparse_nfs_data *nfs; >> }; >> } reparse; >> struct { >> diff --git a/fs/smb/client/cifspdu.h b/fs/smb/client/cifspdu.h >> index c3b6263060b0..fefd7e5eb170 100644 >> --- a/fs/smb/client/cifspdu.h >> +++ b/fs/smb/client/cifspdu.h >> @@ -1506,7 +1506,7 @@ struct reparse_symlink_data { >> #define NFS_SPECFILE_BLK 0x00000000004B4C42 >> #define NFS_SPECFILE_FIFO 0x000000004F464946 >> #define NFS_SPECFILE_SOCK 0x000000004B434F53 >> -struct reparse_posix_data { >> +struct reparse_nfs_data { >> __le32 ReparseTag; >> __le16 ReparseDataLength; >> __u16 Reserved; >> diff --git a/fs/smb/client/reparse.c b/fs/smb/client/reparse.c >> index 35e8f2e18530..a23ea2f78c09 100644 >> --- a/fs/smb/client/reparse.c >> +++ b/fs/smb/client/reparse.c >> @@ -81,7 +81,7 @@ int smb2_create_reparse_symlink(const unsigned int xid, struct inode *inode, >> return rc; >> } >> >> -static int nfs_set_reparse_buf(struct reparse_posix_data *buf, >> +static int nfs_set_reparse_buf(struct reparse_nfs_data *buf, >> mode_t mode, dev_t dev, >> struct kvec *iov) >> { >> @@ -120,20 +120,20 @@ static int mknod_nfs(unsigned int xid, struct inode *inode, >> const char *full_path, umode_t mode, dev_t dev) >> { >> struct cifs_open_info_data data; >> - struct reparse_posix_data *p; >> + struct reparse_nfs_data *p; >> struct inode *new; >> struct kvec iov; >> __u8 buf[sizeof(*p) + sizeof(__le64)]; >> int rc; >> >> - p = (struct reparse_posix_data *)buf; >> + p = (struct reparse_nfs_data *)buf; >> rc = nfs_set_reparse_buf(p, mode, dev, &iov); >> if (rc) >> return rc; >> >> data = (struct cifs_open_info_data) { >> .reparse_point = true, >> - .reparse = { .tag = IO_REPARSE_TAG_NFS, .posix = p, }, >> + .reparse = { .tag = IO_REPARSE_TAG_NFS, .nfs = p, }, >> }; >> >> new = smb2_get_reparse_inode(&data, inode->i_sb, xid, >> @@ -313,7 +313,7 @@ int smb2_mknod_reparse(unsigned int xid, struct inode *inode, >> } >> >> /* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */ >> -static int parse_reparse_posix(struct reparse_posix_data *buf, >> +static int parse_reparse_nfs(struct reparse_nfs_data *buf, >> struct cifs_sb_info *cifs_sb, >> struct cifs_open_info_data *data) >> { >> @@ -414,7 +414,7 @@ int parse_reparse_point(struct reparse_data_buffer *buf, >> /* See MS-FSCC 2.1.2 */ >> switch (le32_to_cpu(buf->ReparseTag)) { >> case IO_REPARSE_TAG_NFS: >> - return parse_reparse_posix((struct reparse_posix_data *)buf, >> + return parse_reparse_nfs((struct reparse_nfs_data *)buf, >> cifs_sb, data); >> case IO_REPARSE_TAG_SYMLINK: >> return parse_reparse_symlink( >> @@ -507,7 +507,7 @@ bool cifs_reparse_point_to_fattr(struct cifs_sb_info *cifs_sb, >> struct cifs_fattr *fattr, >> struct cifs_open_info_data *data) >> { >> - struct reparse_posix_data *buf = data->reparse.posix; >> + struct reparse_nfs_data *buf = data->reparse.nfs; >> u32 tag = data->reparse.tag; >> >> if (tag == IO_REPARSE_TAG_NFS && buf) { >> diff --git a/fs/smb/client/reparse.h b/fs/smb/client/reparse.h >> index 5be54878265e..2a91f64de557 100644 >> --- a/fs/smb/client/reparse.h >> +++ b/fs/smb/client/reparse.h >> @@ -18,7 +18,7 @@ >> */ >> #define IO_REPARSE_TAG_INTERNAL ((__u32)~0U) >> >> -static inline dev_t reparse_nfs_mkdev(struct reparse_posix_data *buf) >> +static inline dev_t reparse_nfs_mkdev(struct reparse_nfs_data *buf) >> { >> u32 major, minor; >> >> diff --git a/fs/smb/common/smb2pdu.h b/fs/smb/common/smb2pdu.h >> index c769f9dbc0b4..0e77a4c0145a 100644 >> --- a/fs/smb/common/smb2pdu.h >> +++ b/fs/smb/common/smb2pdu.h >> @@ -1550,7 +1550,7 @@ struct reparse_symlink_data_buffer { >> __u8 PathBuffer[]; /* Variable Length */ >> } __packed; >> >> -/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_posix_data */ >> +/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_nfs_data */ >> >> struct validate_negotiate_info_req { >> __le32 Capabilities; >> -- >> 2.20.1 >> >> > >
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? Anyway, Windows clients mostly do not use IO_REPARSE_TAG_NFS. 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. 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. To my knowledge neither Samba, nor Linux CIFS client supports "NfsSymlinkTargetName" EA for creating or parsing symlink. On Sunday 29 September 2024 11:09:44 Ralph Boehme wrote: > Keep in mind that the inode type info will also be available via the posix > infolevel in the mode bits. The changes for Samba by Volker have already > been merged last week. > > Spec draft: > > https://gitlab.com/samba-team/smb3-posix-spec/-/merge_requests/2 > > <https://www.samba.org/~slow/SMB3_POSIX/fscc_posix_extensions.html#posix-mode> > > Fwiw, in a future version of POSIX-FSA we will probably say that in POSIX > mode (per handle) the POSIX client MUST use the POSIXMode field for the > inode type and one MUST NOT use the NFS reparse point tag for this. The > server in POSIX mode MAY also set the reparse tag, but that's still open to > debate from my pov. > > The NFS reparse tag will be there basically for the Windows clients in > non-POSIX mode and support will be mandatory in the server. The only reparse > tag we'd in POSIX mode for inode type information would be > IO_REPARSE_TAG_SYMLINK for symlinks. > > -slow > > > On 9/29/24 6:57 AM, Steve French wrote: > > since they are being used by default for servers supporting special > > files in the "SMB3.1.1 POSIX Extensions" ... it might be appropriate > > to keep a less confusing name ("NFS" for "SMB3.1.1 POSIX" could be > > confusing) > > > > On Sat, Sep 28, 2024 at 5:01 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > This function parses NFS-style reparse points, which are used only by > > > Windows NFS server since Windows Server 2012 version. This style of special > > > files is not understood by Microsoft POSIX / Interix / SFU / SUA subsystems. > > > > > > So make it clear that parse_reparse_posix() function and reparse_posix_data > > > structure are not POSIX general, but rather NFS specific. > > > > > > Signed-off-by: Pali Rohár <pali@kernel.org> > > > --- > > > fs/smb/client/cifsglob.h | 2 +- > > > fs/smb/client/cifspdu.h | 2 +- > > > fs/smb/client/reparse.c | 14 +++++++------- > > > fs/smb/client/reparse.h | 2 +- > > > fs/smb/common/smb2pdu.h | 2 +- > > > 5 files changed, 11 insertions(+), 11 deletions(-) > > > > > > diff --git a/fs/smb/client/cifsglob.h b/fs/smb/client/cifsglob.h > > > index 9eae8649f90c..119537e98f77 100644 > > > --- a/fs/smb/client/cifsglob.h > > > +++ b/fs/smb/client/cifsglob.h > > > @@ -223,7 +223,7 @@ struct cifs_open_info_data { > > > __u32 tag; > > > union { > > > struct reparse_data_buffer *buf; > > > - struct reparse_posix_data *posix; > > > + struct reparse_nfs_data *nfs; > > > }; > > > } reparse; > > > struct { > > > diff --git a/fs/smb/client/cifspdu.h b/fs/smb/client/cifspdu.h > > > index c3b6263060b0..fefd7e5eb170 100644 > > > --- a/fs/smb/client/cifspdu.h > > > +++ b/fs/smb/client/cifspdu.h > > > @@ -1506,7 +1506,7 @@ struct reparse_symlink_data { > > > #define NFS_SPECFILE_BLK 0x00000000004B4C42 > > > #define NFS_SPECFILE_FIFO 0x000000004F464946 > > > #define NFS_SPECFILE_SOCK 0x000000004B434F53 > > > -struct reparse_posix_data { > > > +struct reparse_nfs_data { > > > __le32 ReparseTag; > > > __le16 ReparseDataLength; > > > __u16 Reserved; > > > diff --git a/fs/smb/client/reparse.c b/fs/smb/client/reparse.c > > > index 35e8f2e18530..a23ea2f78c09 100644 > > > --- a/fs/smb/client/reparse.c > > > +++ b/fs/smb/client/reparse.c > > > @@ -81,7 +81,7 @@ int smb2_create_reparse_symlink(const unsigned int xid, struct inode *inode, > > > return rc; > > > } > > > > > > -static int nfs_set_reparse_buf(struct reparse_posix_data *buf, > > > +static int nfs_set_reparse_buf(struct reparse_nfs_data *buf, > > > mode_t mode, dev_t dev, > > > struct kvec *iov) > > > { > > > @@ -120,20 +120,20 @@ static int mknod_nfs(unsigned int xid, struct inode *inode, > > > const char *full_path, umode_t mode, dev_t dev) > > > { > > > struct cifs_open_info_data data; > > > - struct reparse_posix_data *p; > > > + struct reparse_nfs_data *p; > > > struct inode *new; > > > struct kvec iov; > > > __u8 buf[sizeof(*p) + sizeof(__le64)]; > > > int rc; > > > > > > - p = (struct reparse_posix_data *)buf; > > > + p = (struct reparse_nfs_data *)buf; > > > rc = nfs_set_reparse_buf(p, mode, dev, &iov); > > > if (rc) > > > return rc; > > > > > > data = (struct cifs_open_info_data) { > > > .reparse_point = true, > > > - .reparse = { .tag = IO_REPARSE_TAG_NFS, .posix = p, }, > > > + .reparse = { .tag = IO_REPARSE_TAG_NFS, .nfs = p, }, > > > }; > > > > > > new = smb2_get_reparse_inode(&data, inode->i_sb, xid, > > > @@ -313,7 +313,7 @@ int smb2_mknod_reparse(unsigned int xid, struct inode *inode, > > > } > > > > > > /* See MS-FSCC 2.1.2.6 for the 'NFS' style reparse tags */ > > > -static int parse_reparse_posix(struct reparse_posix_data *buf, > > > +static int parse_reparse_nfs(struct reparse_nfs_data *buf, > > > struct cifs_sb_info *cifs_sb, > > > struct cifs_open_info_data *data) > > > { > > > @@ -414,7 +414,7 @@ int parse_reparse_point(struct reparse_data_buffer *buf, > > > /* See MS-FSCC 2.1.2 */ > > > switch (le32_to_cpu(buf->ReparseTag)) { > > > case IO_REPARSE_TAG_NFS: > > > - return parse_reparse_posix((struct reparse_posix_data *)buf, > > > + return parse_reparse_nfs((struct reparse_nfs_data *)buf, > > > cifs_sb, data); > > > case IO_REPARSE_TAG_SYMLINK: > > > return parse_reparse_symlink( > > > @@ -507,7 +507,7 @@ bool cifs_reparse_point_to_fattr(struct cifs_sb_info *cifs_sb, > > > struct cifs_fattr *fattr, > > > struct cifs_open_info_data *data) > > > { > > > - struct reparse_posix_data *buf = data->reparse.posix; > > > + struct reparse_nfs_data *buf = data->reparse.nfs; > > > u32 tag = data->reparse.tag; > > > > > > if (tag == IO_REPARSE_TAG_NFS && buf) { > > > diff --git a/fs/smb/client/reparse.h b/fs/smb/client/reparse.h > > > index 5be54878265e..2a91f64de557 100644 > > > --- a/fs/smb/client/reparse.h > > > +++ b/fs/smb/client/reparse.h > > > @@ -18,7 +18,7 @@ > > > */ > > > #define IO_REPARSE_TAG_INTERNAL ((__u32)~0U) > > > > > > -static inline dev_t reparse_nfs_mkdev(struct reparse_posix_data *buf) > > > +static inline dev_t reparse_nfs_mkdev(struct reparse_nfs_data *buf) > > > { > > > u32 major, minor; > > > > > > diff --git a/fs/smb/common/smb2pdu.h b/fs/smb/common/smb2pdu.h > > > index c769f9dbc0b4..0e77a4c0145a 100644 > > > --- a/fs/smb/common/smb2pdu.h > > > +++ b/fs/smb/common/smb2pdu.h > > > @@ -1550,7 +1550,7 @@ struct reparse_symlink_data_buffer { > > > __u8 PathBuffer[]; /* Variable Length */ > > > } __packed; > > > > > > -/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_posix_data */ > > > +/* See MS-FSCC 2.1.2.6 and cifspdu.h for struct reparse_nfs_data */ > > > > > > struct validate_negotiate_info_req { > > > __le32 Capabilities; > > > -- > > > 2.20.1 > > > > > > > > > > >
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
On Sun, Sep 29, 2024 at 7:52 AM Ralph Boehme <slow@samba.org> 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
© 2016 - 2024 Red Hat, Inc.