Hi, It would be helpful to better understand the original design intention here. Not knowing the semantic intent of whatever remote update has taken place, the cm cannot reliably decide what is a compatible update. Assuming that no remote change is compatible with any local change contradicts, at least, extended callbacks StoreData assumptions. Nb., cache bypass semantics and direct io (yfs) already affect this behavior for those respective special cases, iiuc.
Matt ----- "Simon Wilkinson" <[email protected]> wrote: > On 11 Apr 2011, at 20:47, Russ Allbery wrote: > > > Simon Wilkinson <[email protected]> writes: > > > >> 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) > > > > Or when you call fflush, no? > > The code here is pretty gnarly, but yeah - calling fsync should clear > the IFDataMod flag which stops us from getting new data from the > server, and so result in you seeing new data, providing you don't > write anything else to the file. > > Cheers, > > Simon. > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
