Russ Allbery wrote:
Jeffrey Altman <[EMAIL PROTECTED]> writes:What normal successfully completed operation is leaving unreferenced .__afsNNNN files behind? Lets fix the bug.Good question. I know we accumulate a ton of them that get cleaned up on each salvage, but I have no idea how to figure out what's creating them and leaving them behind.
Read some code and spoke with Derrick a bit about this. Here is what is going on. There isn't a bug here. If you look at the AFS UNIX cache manager code you will see that the __afsNNNN files are the result of an existing file being renamed by the cache manager in src/afs/VNOPS/afs_vnop_remove.c when unlink() has been called by an application on a file that is currently in use. In other words, the .__afsNNNN files are unnamed files that as far as the file server is concerned are still in use by some client. The reason the files are left behind is because the AFS cache manager that renamed the file did not delete it before it lost contact with the file server (network dropped, cache manager was stopped, machine crashed, ...). Since the file server has no way of knowing if the file is still in use it can't delete it. Or we should say it doesn't delete them. It can be argued that it isn't even safe to delete them by taking the volume temporarily offline and performing the salvage operation because the salvager has no knowledge of whether or not the files are in use. It could certainly be the case that a policy could be put in place to delete them after some period of time. However nothing would be absolutely safe for all circumstances. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
