Chris Pickett wrote: > >You would need to find the process that has the file open and deal > >with it (probably by killing it) first. Using tools such as 'fuser' > >and 'lsof' or their equivalents on your system can be useful here. > > ~/test $ rm -rf autom4te.cache > rm: cannot remove directory `autom4te.cache': File exists > ~/test $ ll autom4te.cache/ > total 12K > -rw-r--r-- 1 pickett xxx 12K Feb 23 10:39 .nfsD1831 > ~/test $ rm autom4te.cache/.nfsD1831 > ~/test $ ll autom4te.cache/ > total 12K > -rw-r--r-- 1 pickett xxx 12K Feb 23 10:39 .nfsE1831 Right. Exactly as desribed. The nfs client believes there is an open file descriptor to that file and therefore renames it instead of removing it. You can move it elsewhere, such as out of that directory, and then the directory will be empty and can be removed. If the directory itself is busy such as with the current working directory of a process then repeat with the directory itself. > ~/test $ fuser autom4te.cache/.nfsE1831 > autom4te.cache/.nfsE1831: > ~/test $ fuser autom4te.cache/ > autom4te.cache/: > ~/test $ fuser -d -u -V autom4te.cache/.nfsE1831 > autom4te.cache/.nfsE1831: I have seen that too. I don't know why one behavior indicates an open file with an active process and another one refuses to show anything for it showing that there aren't any. I didn't say that the system would help you out and tell you good information. All NFS users have a rich environment to whine about problems. It is a target rich environment. > ~/test $ fuser -d -u -V autom4te.cache/ > autom4te.cache/: > > ~/test $ lsof > -bash: lsof: command not found Well, I did say "or equivalents". I think lsof is more closely associated with systems supporting /proc but don't really know the history of it. Using fuser is probably your only choice. I don't know if that needs root access on your system to provide meanful information or not. Also, I seem to recall needing the -m option on other systems. > I have nothing else besides login processes running. It is possible > that root has something, but I don't know what it is. > > ~/test $ ps auxww | grep root | grep nfs I doubt the process would be named "*nfs*" anything. It is more likely to be one of the tools called by scripts such as grep, sed, awk, and so forth. Since you ran the autotools scripts the process should be owned by you. (The security model of the system will prevent you from escalating your privilege to a root process.) > >As a first pass I would try using a local directory instead of over > > Yes, building in /tmp works, A good data point. Since the local disk works it definitely confirms nfs as being involved with the problem. > but since I need NFS access the .autom4te.cfg trick is better for me. Sure. I understand. But unfortunately it does tie in the vendor nfs of the system into the problem. That is an "immovable object". Can you provide an "irresistible force" to oppose it? :-) More seriously if this can be narrowed down to the exact details that trigger this problem then workarounds might be applied. But this is probably going to need to be left in your hands to do debug since you have the test case for it. Any help you can provide to expose details is appreciated. Bob _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
