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

[Uri Simchoni]

On 12/4/18 4:48 PM, Noel Power via samba-technical wrote:
> Hi All,
> 
<snip>

> So probably best first to tell what the current problem is,
> 
> If you have a SAMBA share (where the directory is on device
> /dev/deviceA) and somewhere in the the tree of children you have a
> folder which is a mountpoint to a directory on a different device (e.g.
> /dev/deviceB) then the following happens
> 
> a) The quotas associated with /dev/deviceA are also applied to the
> folders that are located on /dev/deviceB, very annoying if the quota on
> /dev/deviceB hasn't been exceeded and you should still be able to write
> stuff to this device but the quota has been reached on /dev/deviceA  so
> you can't :-)
> 
> b) The free space capacity of /dev/deviceA is used throughout the share
> (including those folders located on a difference device) this is of
> course also annoying if the capacity of /dev/deviceA is smaller (or has
> no space left) and there is plenty of space on /dev/deviceB meaning you
> cannot write to folders that are on /dev/deviceB even though there is
> plenty of free capacity
> 

I'm a bit puzzled. Indeed, SMB1 didn't have the capability of querying
disk space relative to a path, and this capability is added in SMB2.
However, we're passing the path from the protocol all the way to
SMB_VFS_DISK_FREE(), and to SMB_VFS_GET_QUOTA(), and in the default
backend we use this path. We have tests for the SMB layer using a custom
VFS module that fakes free disk and quotas.

Back when I was into quotas, I kind-of tested this in the field, but not
using mount points. We used "inherit owner" and in that case, the quota
used for free-disk calculation is that of the owner, because that's the
likeliest user to affect new file's quota. Nevertheless you get the
effect that same user is getting different quotas on different paths,
and, consequently, different free disk space, and it seemed to work.
Without fixing the free-disk query to behave so with relation to
inherit-owner, Windows Explorer would refuse to copy files into the
inherit-owner directories if the user didn't have enough quota, but this
has been fixed long ago and is tested.

The reparse point is probably needed for something, or this wouldn't
have come up, but as long as we try to state the problem clearly - can
you correct me where I'm wrong?

Thanks,
Uri.