Thank you. I guessed that it would be this way, but I thought that it's better to ask for ensuring.
On Mon, Apr 11, 2011 at 2:19 PM, Simon Wilkinson <s...@inf.ed.ac.uk> wrote: > > (removed openafs-devel) > > On 11 Apr 2011, at 10:58, Meisam Mohammadkhani < > meisam.mohammadkh...@gmail.com> wrote: > > "The callback mechanism does not guarantee that you immediately see the > changes someone else makes to a file you are using. Your Cache Manager does > not notice the broken callback until your application program asks it for > more data from the file." > > > > Does that mean if we read for example first 100 Bytes of the file, > repeatedly, if main file changes, callbacks don't inform the cache manager, > until we read for example byte 101? > > No. > > What it means is that an application which has read() some data from a file > won't be notified by the cache manager that that data has changed. There's > no mechanism in POSIX for the kernel to do so. However, If the application > then read()s that data again it will be given the most recent version - so > if a callback has expired, then the cache manager will fetch the new data > from the fileserver, and you will get the newest file. > > There is one exception to this behaviour on Unix. If you have opened a file > for writing, and dirtied that file, then the version of the data on your > client remains that at the point the file was dirtied - any subsequent > changes on the fileserver won't be delivered to your client until you close > the open file handle (and the data is sent to the server) > > Cheers, > > Simon.
