linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: Tom Talpey <tom@talpey.com>
Cc: Namjae Jeon <linkinjeon@kernel.org>, CIFS <linux-cifs@vger.kernel.org>
Subject: Re: [PATCH] ksmbd: add default data stream name in FILE_STREAM_INFORMATION
Date: Mon, 20 Sep 2021 11:36:54 -0500	[thread overview]
Message-ID: <CAH2r5msyrGTGTfq58yB70v2QJG4c596pPPHWgxqEHAW0nJ5ykQ@mail.gmail.com> (raw)
In-Reply-To: <2cf8a2d1-41df-eef4-dfe0-dca076e8db54@talpey.com>

On Mon, Sep 20, 2021 at 11:08 AM Tom Talpey <tom@talpey.com> wrote:
>
> On 9/20/2021 12:47 AM, Steve French wrote:
> > On Sat, Sep 18, 2021 at 9:06 PM Tom Talpey <tom@talpey.com> wrote:
> >>
> >> This doesn't appear to be what's documented in MS-FSA section 2.1.5.11.29.
> >> There, it appears to call for returning an empty stream list,
> >> and STATUS_SUCCESS, when no streams are present.
> >
> > I tried a quick test to Windows and it does appear to return $DATA
> > stream by default:
> >
> > # ./smbinfo filestreaminfo /mnt/junk
> > Name: ::$DATA
> > Size: 179765 bytes
> > Allocation size: 196608 bytes
>
> Ok, so the implication is that the default stream is indeed always
> present, if the filesystem supports streams. The language in MS-FSA
> would therefore be correct, but a bit vague. I agree that returning
> a ::$DATA for ordinary files is appropriate.
>
> > when I tried the same thing to a directory on a share mounted to Windows 10
> > (NTFS), I get no streams returned.
> >
> > So it does look like default stream ($DATA) is only returned for files
>
>
> My concern here is, what's so special about directories? A special file
> or fifo, a symlink or reparse/junction, etc. Is it appropriate to cons
> up a ::$DATA for these? What should the size values be, if so?

Here are examples (share exported Windows 10 NTFS) of files vs.
directories with or without streams, note that directories do not show
the "default stream" $DATA but files do, but both support adding
streams, and reparse points at least in the case of hardlinks to files
show the target's streams.  It is a bit confusing because the Windows
"dir /R" command filters out the ($DATA) stream returned on files even
though it is returned across the network.

# smbinfo filestreaminfo /mnt/dir-without-stream/


# smbinfo filestreaminfo /mnt/dir-with-stream/
Name: test_stream
Size: 19 bytes
Allocation size: 24 bytes


# smbinfo filestreaminfo /mnt/file-without-stream
Name: ::$DATA
Size: 24 bytes
Allocation size: 24 bytes


# smbinfo filestreaminfo /mnt/file-with-stream
Name: ::$DATA
Size: 17 bytes
Allocation size: 24 bytes

Name: test_stream
Size: 19 bytes
Allocation size: 24 bytes


# smbinfo filestreaminfo /mnt/link-file-with-stream
Name: ::$DATA
Size: 17 bytes
Allocation size: 24 bytes

Name: test_stream
Size: 19 bytes
Allocation size: 24 bytes


# smbinfo filestreaminfo /mnt/link-file-without-stream
Name: ::$DATA
Size: 24 bytes
Allocation size: 24 bytes

Note that locally on Windows "DIR /R" filters out the $DATA (default) stream

C:\shares\scratch>dir /R \shares\scratch
 Volume in drive C is OSDisk
 Volume Serial Number is 0AF4-9CC1

 Directory of C:\shares\scratch

09/20/2021  11:32 AM    <DIR>          .
09/20/2021  11:32 AM    <DIR>          ..
09/20/2021  11:16 AM    <DIR>          dir-with-stream
                                    19 dir-with-stream:test_stream:$DATA
09/20/2021  11:15 AM    <DIR>          dir-without-stream
09/20/2021  11:14 AM                17 file-with-stream
                                    19 file-with-stream:test_stream:$DATA
09/20/2021  11:14 AM                24 file-without-stream
09/20/2021  11:14 AM                17 link-file-with-stream
                                    19 link-file-with-stream:test_stream:$DATA
09/20/2021  11:14 AM                24 link-file-without-stream


--
Thanks,

Steve

      parent reply	other threads:[~2021-09-20 16:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-18 12:02 [PATCH] ksmbd: add default data stream name in FILE_STREAM_INFORMATION Namjae Jeon
2021-09-18 12:39 ` Tom Talpey
2021-09-18 21:36   ` Namjae Jeon
2021-09-20  4:47   ` Steve French
2021-09-20  4:53     ` Steve French
2021-09-20 16:08     ` Tom Talpey
2021-09-20 16:34       ` Namjae Jeon
2021-09-21 18:19         ` Tom Talpey
2021-09-21 19:17           ` Steve French
2021-09-20 16:36       ` Steve French [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH2r5msyrGTGTfq58yB70v2QJG4c596pPPHWgxqEHAW0nJ5ykQ@mail.gmail.com \
    --to=smfrench@gmail.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).