Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

SMB, Junctions, Symlinks and Reparse Points

Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
Hello,

I have some curiosity regarding how SMB file sharing works in Windows.
Specifically, what is done in UM and what is done in KM, how is the
SMB server notified when an OpLock is broken and how does the server
interact with Junctions, Symlinks or Reparse Points.

A SMB file sharing daemon could be implemented entirely in userspace
and use the regular user space I/O API to access the underlying File
System. This is what Samba does on UNIX and UNIX-like operating
systems. Some things are better if you have Kernel support though. For
example, an OpLock is not broken only in the case if a remote client
tries to access a file opened previously by another remote client, but
it should also be broken if that file is opened locally. Also, the
local call to CreateFile() should be blocked in the file system stack
until the OpLock would have been broken and acknowledged remotely, to
preserve SMB semantics and cache coherency. This thinks cannot happen
without kernel support. I am curious about the way Windows does this.
What exactly is implemented in KM and what in UM?

I am also curious about how the SMB server handles Junctions, Symlinks
and Reparse Points. Is everything implemented in the File System stack
or does the server implement some explict support. If I `dir' a remote
share, I still see Junctions and Symlinks, not the targets themselves.
How is this implemented?

Thanks,

--
Aram Hăvărneanu

Comments

  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    > I have some curiosity regarding how SMB file sharing works in Windows.
    > Specifically, what is done in UM and what is done in KM, how is the
    > SMB server notified when an OpLock is broken and how does the server
    > interact with Junctions, Symlinks or Reparse Points.

    Last few days I have investigated the LanMan SRV. It seems SRV (and
    SRV2) is implemented by a user mode network server that communicates
    with a kernel mode file system (implemented in srv.sys and srv2.sys)
    by TDI. I have some questions regarding this.

    SRV is implemented as a file system but it's not a real file system.
    It's only functional dispatch function is for FSCTL. Why is SRV a file
    system when a simple driver would have done just fine?

    SRV seems to bypass the I/O manager. It seems to do this for
    efficiency. SRV tries to call the FAST I/O routines directly and if it
    doesn't succeed, it creates IRPs manually instead of relying on the
    I/O manager. This IRPs are never completed by the I/O manager and they
    are reused, the server seems to keep a pool of IRPs to use them as
    necessary -- it doesn't create an IRP for every operation. Also SRV
    avoids an additional memory copy by using the raw MDLs when completing
    requests. How does SRV know the target DeviceObject of the underlying
    FSD it requires for a certain operation? Normally, with Zw*File() API
    IRPs are created by the I/O manager and the I/O manager determines the
    target DO. How does SRV do this? Also, what are the advantages or
    manually creating IRPs instead of calling Zw*File() *AFTER* it was
    determined (via the FAST I/O path) that the requested data is not in
    the cache. The request would be processed in the FSP anyway, and the
    I/O manager overhead for non-cached data would seem minor.

    Thanks,

    --
    Aram Hăvărneanu
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space