[Patch] dosmode: Compare block devices to detect reparse points
james at et.byu.edu
Mon Jan 28 23:40:08 UTC 2019
I'm attaching a revision of the patch that makes use of your idea to
re-use the parent directory stat on a FIND operation. Turns out that it
works beautifully, no additional stat calls needed there.
However, I encountered a snag when I implemented just that. It seems
that when a Windows 10 File Explorer client opens a reparsepoint-marked
directory sends a CREATE request targeting that directory, the client
overwrites its reparsepoint state for that directory. In effect, if you
enter a directory and then quickly leave and re-enter it, write and copy
operations "forget" that there was ever a reparsepoint file attribute set.
To fix that, I mimicked the CREATE flag that Windows File Server
returns. This is not in the file attributes bit field, but has the
effect of preserving the set FILE_ATTRIBUTE_REPARSEPOINT returned in the
FIND response. Detecting the mountpoint here requires an additional stat
for each CREATE that targets a directory.
Let me know what you think.
On 12/5/18 04:57, Noel Power wrote:
> Hi Jeremy
> On 04/12/2018 22:55, Jeremy Allison wrote:
>> On Tue, Dec 04, 2018 at 10:46:13PM +0000, Noel Power wrote:
>>>> We set it on MS-DFS links because we handle them the right way
>>>> in smbd on client query.
>>> I'll have to look into it but I don't see (like you said) any
>>> handling of
>>> FILE_OPEN_REPARSE_POINT for the tag IO_REPARSE_TAG_DFS So.. not sure
>>> MS-DFS client queries you mean (but I know practically nothing about
>> Well you can't query IO_REPARSE_TAG_DFS over the network. Once it
>> hits an MS-DFS reparse point it returns the required error on
>> processing the pathname inside smbd - that's what I mean by
>> MS-DFS client queries :-).
>>> well we could handle FILE_OPEN_REPARSE_POINT at least for
>>> mountpoints (only
>>> if we have a config option for it set) iirc when opening a reparse
>>> point you
>>> just need to return the tag associated with the reparse point (in
>>> this case
>>> IO_REPARSE_TAG_MOUNT_POINT) if and only if the file
>> No, it's much nastier than that. Reparse points have a hideously
>> complex set of requirements (you can mkdir, turn into a reparse
>> point, open it, remove the reparse tag, turn it back into a directory
>> etc. etc. etc.). And that's just for directories. The same thing
>> happens for files.
> But we are not trying to implement or handle any of what you are
> mentioning above, what I am suggesting here is to provide just a very
> very tight limited READ-ONLY handling of requests to do with
> IO_REPARSE_TAG_MOUNT_POINT type tags, nothing else
> If we want to handle open then we only handle it for a directory that
> *is* a mountpoint *and* if the appropriate config is set, otherwise do
> whatever we do currently (nothing or error)
> If we wish to allow the reparse point to be read (again only handle
> IO_REPARSE_TAG_MOUNT_POINTs) then its only a case of handling
> FSCTL_GET_REPARSE_POINT requests depending on the file handle (if it
> points to a mountpoint with the appropriate configuration set)
> otherwise reject or error out as appropriate
> The data to be provided is quite simple (see
>> Once we start returning FILE_ATTRIBUTE_REPARSE_POINT we've opened
>> a hideous can of worms. That's why in my POSIX tree I restrict
>> allowing reparse points to zero-length files only, no directories,
>> on a POSIX open handle only.
>> You're planning to gung-ho add FILE_ATTRIBUTE_REPARSE_POINT to
>> a directory DOS attribute value. That's my nightmare :-).
> I'm not (or at least I don't think I am :-)) the patch adds
> FILE_ATTRIBUTE_REPARSE_POINT only for shares that have the the feature
> enabled and where a particular directory is seen to be a mountpoint.
> Even without supporting FILE_OPEN_REPARSE_POINT I still don't see this
> is much different from what we do for DFS currently
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9601 bytes
Desc: not available
More information about the samba-technical