[Patch] dosmode: Compare block devices to detect reparse points

[Daniel Fussell]

On 12/4/18 3:55 PM, Jeremy Allison via samba-technical wrote:

> 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. Plus if we transit a reparse point that's stored
> on a directory in pathname processing we won't notice.

In general, the user usually ends up browsing with Explorer to the
destination they want to copy to, thus discovering the mount point en
route.  So the client is now an informed participant.

I've tried testing the uninformed client case by opening an Explorer at
a specific path below a mount point, and so far have not been able to
trigger a failure.  I haven't packet traced it yet, but my guess is,
Explorer still traverses the SMB path and discovers the reparse point,
or naturally pulls an FSFullInfo at the destination on open.  But again,
at this point, it's a guess.

I have not tried it from code, but I don't write Windows code.  From
CLI, copy/xcopy/robocopy don't seem to care about destination free
space, so they have been our go-to work around since later releases of
Samba 3.6.  My engineers roll their eyes a bit at the work around, but
my secretaries have not been nearly as understanding.

> 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 . It
> has *meaning* to a whole host of Windows apps you're not at
> all prepared to cope with.
>
> What will backup apps start to do then ? It's likely all
> backup apps will now start failing against Samba servers
> once they cross a mount point (hey, why can't I read the
> reparse point data to backup - you told me it was a reparse
> point ?).

Well, regarding backups of reparse points failing, I'd say "Don't do
that'... 

But seriously, if we need to handle an IOCTRL to read the reparse data
of a volume mountpoint, fine.  We have to do so for Symlinks anyway.  We
presently handle DFS reparse points and you are planning on adding
SYMLinks.  I think adding the volume mount point tag reasonable, even if
it means more work.  If you want me to put my neurotransmitters where my
mouth is, I'd be willing to work it out with you on your SMB2-POSIX branch.

>> The client could only then get/set/delete the reparse point (but support for
>> these is afaics optional) We probably really don't want a client to be able
>> to create/delete/change an existing mount point on linux, it's possible but
>> would we really want to do it ? For the get reparse point operation we could
>> return some data (but that data probably would be useless to the client) So
>> it's debatably how useful implementing anything other than a stub that
>> returns STATUS_INVALID_DEVICE_REQUEST would be
> If you start returning FILE_ATTRIBUTE_REPARSE_POINT on a directory,
> you're promising a million things we're not prepared to support.
>
> Don't do that.

Yes, promises can hurt,  and I may be naive, but I don't think this one
will.

>From what I can tell in the documentation (MS-FSCC 2.1.2.1 Reparse Tags,
3rd paragraph), SMB2 symlinks (not posix symlinks) are the only reparse
points an SMB2 client is expected to do anything with.  Everything else
is supposedly for the client's information only, and handled only by
server-side FS filters.  Feel free to correct me if I misunderstood
(which is clearly possible, I've done so before).  From what the packet
traces say to me, you only get reparse tag/buffer data if the client
decides it wants to issue an FSCTL to read a tag from a reparse point
flagged file.

I could be wrong, and I'll admit that.  It is possible we may have to
come up with a more thorough implementation of reparse points to handle
any arbitrary and site-specific use of global and custom reparse tags. 
All I'm interested in is basic reparse flags on mountpoints, so Explorer
will handle free space appropriately, and my users will stop telling me
it's broken.  That said, I'm willing to put work into areas I'll never
use, simply so we all can benefit.  

Daniel