Hi, Well, it certainly could do the latter.
Matt ----- "Simon Wilkinson" <[email protected]> wrote: > On 25 Feb 2012, at 23:54, Matt W. Benjamin wrote: > > > well, > > > > 1. the response to unlink w/XCB is an indication of unlink > > 2. if rxgk is in use (there is published code of at least alpha > quality implementing, iirc, rxgk with callback channel protection) > > > > So... > > By the time that the callback break arrives, the file has already > disappeared from the view of the client. So, even with extended > callbacks the client doesn't have a chance to grab any chunks of the > file that it may be missing. You'd also require that a client > constantly refresh callbacks for any files which it has open, which > has potential fileserver performance implications. > > I think any solution to this problem is going to depend upon defining > new RPC behaviour - either for an open/close pair (which has issues > potential issues with malicious, or disappearing clients), or in > allowing deleted content to persist on the fileserver so that it can > be fetched by a client receiving a callback break. > > Cheers, > > Simon. > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel -- 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-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
