(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._______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
