On Tue, Jan 24, 2012 at 2:52 PM, Andrew Deason <[email protected]> wrote: > Someone asked me about this recently, and I don't have a good > explanation of why this is the current behavior. > > Currently, a fileserver will NOT break callbacks for a file that is > being removed. If it gets unlinked and the link count remains above 0, > we of course do break callbacks since that's just a number changing in > the metadata, but we don't when the file actually goes away. This is > this section in the fileserver, in afsfileprocs.c in SAFSS_RemoveFile: > > /* Handle internal callback state for the parent and the deleted file */ > if (targetptr->disk.linkCount == 0) { > /* no references left, discard entry */ > DeleteFileCallBacks(&fileFid); > [...] > } else { > [...] > /* tell all the file has changed */ > BreakCallBack(client->host, &fileFid, 1); > }
This was in AFS 3.0 beta, 1989, and was in every revision I have back to the initial September 1988 version of the file I have. -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
