Re:upcalls seem to have problems with symlinks, junctions et al.

[L A Walsh <cifs@tlinx.org>]

On 2/20/2019 11:48 AM, L A Walsh wrote:
>
>>> ---
>>> ls: cannot access 'Documents': Operation not supported
>>> ...
>>> ls: cannot access 'Prog64': Operation not supported
>>>       
>>> d????????? ?       ?            ? Documents/
>>> ...
>>> d????????? ?       ?            ? Prog64/
>>> ...
>>> Depending on timing, Sometimes I will get most or all of
>>> them appearing the same as they would on windows.
>>>
>>> If I can't resolve them more quickly, is there a know
>>> or two to increase cache size and item lifetime?
>>>     
>>>       
>> Which kernel version shows symlinks right and which - wrong?
>>     
----
    Wrong is 4.20.3... I'm not sure, using the "upcall" for the linux
client reading Metadata(owner+ACL) has ever worked right
for the various forms of symlink/symlinkd/mountd/junction, since
I see a message from me on the cifs list trying 4.10.1 and
having resolution problems related to file-system redirects.

    They "should" work the same way...as when I list them locally
since I'm accessing the machine as the same user (the linux
machine is a samba4 PDC and I'm using the same user-id to
access it on both sides).

    The only time they fully work is when I assigned the mount
ownership to my local user that owns or is in a group that
owns most of the links.  Is there something flakey
about reading the link info -- since it works when I mount
it using 1 UID.

    There may be cache timing issues as well, but they are too
ephemeral to pin down.  The question marks seem to be fairly
consistent on these names (all of which are some form of
NT-pointer to another place - junctions