[Bugs] [Bug 1630804] libgfapi-python: test_listdir_with_stat and test_scandir failure on release 5 branch

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1630804

Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(rgowdapp at redhat.c |
                   |om)                         |



--- Comment #19 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Soumya Koduri from comment #14)
> Okay after a bit of thorough reading, I see that we do not skip dir entries
> (with entry->inode NULL) in the response but just do not perform lookup/link
> their inodes so that any further operation on that dirent, shall force
> lookup.
> 
> So I see two approaches to fix this particular issue -
> * From the commit-msg,
> "translators like readdir-ahead selectively retain entry information of iatt
> (gfid and type) when rest of the iatt is invalidated (for write invalidating
> ia_size, (m)(c)times etc)."
> 
> Since readdir-ahead needs to invalidate attr for only files but not
> directories, it can set entry->inode to NULL and gfapi shall perform lookup
> to link inode and fetch stat before sending the attr to application

Can't gfapi do the same if attr is invalid (even though entry information is
valid)? I am suggesting this because fuse-bridge separates entry and attribute
information and setting entry->inode to NULL (by readdir-ahead) means
fuse-bridge cannot use entry information even though its valid.

> 
> * or if this case needs to be handled for directories as well -->
> 
> we need extra check in the above routine " glfd_entry_refresh()" to validate
> stat and perform lookup if NULL. 

What is the value of stats returned to application if dentry points to
directory?

> 
> Thoughts?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.