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
