It should. It should invalidate the attributes on mdc_lookup_dst, which is what you wanted.
Daniel On 10/13/2016 01:29 PM, Frank Filz wrote: >> I suspect the correct solution is to mark attrs untrusted in >> mdc_unreachable(). > > That doesn't help the entry being renamed though, which is actually the > biggest concern. > > Frank > >> On Wed, Oct 12, 2016 at 6:29 PM, Frank Filz <ffilz...@mindspring.com> >> wrote: >>> Dan, >>> >>> In cache_inode_rename, we did a lookup of both the old name and the >>> new name, and refreshed attributes on both objects. >>> >>> In mdcache, I'm not sure we invalidate the attributes of >>> mdc_lookup_dst (if any, the object that is unlinked as a result of rename >> onto it). >>> >>> What this results in is that a rename of a file causes us to not >>> reflect the updated ctime to the client. >>> >>> I think we need to do an mdc_try_get_cached on old name, and if that >>> results in a cached object, to invalidate it's attributes. >>> >>> Similarly, if mdc_lookup_dst is non-NULL, we need to invalidate it's >>> attributes (if it had multiple hard links, a rename over it should >>> change it's ctime also). If we just evict it from cache, then that works >>> also. >>> >>> What do you think? >>> >>> Anyone else have thoughts? >>> >>> Thanks >>> >>> Frank >>> >>> >>> --- >>> This email has been checked for viruses by Avast antivirus software. >>> https://www.avast.com/antivirus >>> > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
