The .cmake.state files are created and deleted any time a new DO is made during a build. What is happening during your builds is that something has created the .cmake.state file and has a handle to it when something else removes the file. This can happen when you run a recursive make (perhaps you have more than one makefile in the same directory). If you would like to monitor this, you can do the following. Run clearmake, and while it is running, issue "ls -i" on the .cmake.state file. This should show you that the inode changes during the build.
Also (after I reported a reproducible case)
I found the following technote concerning the error message you get:
When running a build I get the following warning:
Clearmake: Warning: Error closing CR cache file .cmake.state - Stale NFS file handle.
There are two conditions that may cause it to appear.
One is if you are automounting vobtags. (Which is, of course, not supported, so don't do it.)
The other is caused by multiple builds executing at the same time or a recursive build. Basically, more than one process is accessing/writing cache and the cache becomes invalid.
The warning message is a benign message. You can safely ignore this message. If you remove all of the .cmake.state files in the tree and rebuild you will not get the warning.
The .cmake.state file is a configuration record cache for derived objects built in the directory that contains the file. Having this file present merely speeds up the build because it avoids having to go to the view or VOB database to get config record information.
As far as the "Stale NFS file handle" errors are concerned, this problem arises when more than one NFS client is using the same filesystem. If one client deletes files or directories in use by a second NFS client, and then the second NFS client goes to reference the deleted object, the NFS server cannot find it on disk and give the "Stale NFS file handle" error.
I also asked and there should not be impact on the possible winkin.