I have wanted to change this code and improve it for a while - one thing which is tricky is showing mode bits when no permissions to read permissions though, and we also need to clean up and simplify some of this code. Let's follow up on this in a few days, if you are flexible and can install some test patches On Thu, Feb 21, 2019 at 5:17 PM L A Walsh <cifs@xxxxxxxxx> wrote: > > 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 > > > > -- Thanks, Steve
