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

[Uri Simchoni]

Thanks Noel. I figured this is the case, but some of this thread (maybe
not your words, on second reading) implied that smbd responds according
to the share's root or volume root. Smbd's responses do reflect the
available disk space for each path, but some clients assume the disk
space is the same unless "warned" by a reparse point.

I suppose my past success with such schemes involved different Windows
client versions (Win7 or Win8 - can't remember right now).

Uri.

On 12/5/18 12:07 AM, Noel Power via samba-technical wrote:
> On 04/12/2018 18:50, Uri Simchoni wrote:
>> 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?
> 
> The problem isn't to do with the disk free calculation or whether it can
> deal with different paths, the problem is the windows client only
> queries  the capacity of the root dir of the share.
> 
> The windows client (I imagine) assumes all child paths are on the same
> device. The reparse point provides the hint that a directory (either a
> mountpoint or a dfs link) is a boundry possibly crossing into another
> filesystem and that is why it's presence will prompt a new capacity
> query of that path.  I can post some traces if that helps
> 
>>
>> Thanks,
>> Uri.
>>
> Noel
> 
>