shared stat cache

[Jeremy Allison]

On Tue, Oct 12, 2004 at 10:59:44AM +0200, Volker.Lendecke at SerNet.DE wrote:
> Hi!
> 
> If you look at the samba4 raw-write test, you will find a subtest called
> test_finfo_after_write. This tries to cover the semantics of the stat entries
> of files returned by windows. Excel 2003 at least on XPSP2 seems to depend on
> this behaviour.
> 
> Here's my comment in locking.c:
> 
> /*******************************************************************
>  Semantics for stat entries to me seem as follows:
> 
>  A file is opened for the first time. This fixes the stat entry
>  returned by call_trans2qfilenameinfo. writes while the file is open
>  does *not* affect the last_write timestamp returned.
> 
>  Another client opens the file and writes. And still there is no
>  change in the last_write timestamp returned.
> 
>  Any connection having written *and* closed the file updates
>  the last_write timestamp on the file.
> ********************************************************************/
> 
> Attached find a first attempt to cover these semantics.
> 
> I did not yet test interactions with setfilepathinfo, this will follow.
> 
> I'm sending this for early review. Is this the right way to solve the problem?

Sorry, just got a chance to look at this. My personal
feeling is that as this info is attached to open files
it should be data associated with the current open file
data in the tdb, not an additional key/value pair. Needs
some testing to check the speed though...

Jeremy.