Since we moved to 5.3 (actually 5.3.2R1P1) we see occasional failures in various Unix automated management procedures. I've finally traced this to the "rm -rf" command failing. On Solaris systems it fails with:
rm -rf /<filer>/x rm: Unable to remove directory /<filer>/x/y/z: File exists
On SGI systems the slightly more meaningful error message is
/<filer>/x/y/z: Directory not empty
However, just repeating the rm -rf command once more works perfectly and the directory tree has gone.
I don't think it's anything to to with CIFS file locking since some of the directories are old and have not been used for a long time. Has anyone else seen this?
Dave Atkin ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk ------------------------------------------------------
I typically see this when I remove a file that is open, and it renames it to .nfs##### - For example if you have a open file on one machine, try to remove it - the nfs system will rename it to .nfs#####. Until you close the open file everytime you try to erase it will get renamed to .nfs####
My guess is that you have a file open when you do the automated `rm -rf` but the file is gone when you try it manully later on.
--Jason
On Tue, Oct 26, 1999 at 08:24:42AM +0000, Dave Atkin wrote:
Since we moved to 5.3 (actually 5.3.2R1P1) we see occasional failures in various Unix automated management procedures. I've finally traced this to the "rm -rf" command failing. On Solaris systems it fails with:
rm -rf /<filer>/x rm: Unable to remove directory /<filer>/x/y/z: File exists
On SGI systems the slightly more meaningful error message is
/<filer>/x/y/z: Directory not empty
However, just repeating the rm -rf command once more works perfectly and the directory tree has gone.
I don't think it's anything to to with CIFS file locking since some of the directories are old and have not been used for a long time. Has anyone else seen this?
Dave Atkin
Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk
In message 19991026080707.O432@concentric.net, "Jason E . Murray" writes:
I typically see this when I remove a file that is open, and it renames it to .nfs##### - For example if you have a open file on one machine, try to remove it - the nfs system will rename it to .nfs#####. Until you close the open file everytime you try to erase it will get renamed to .nfs####
This is an nfs client behavior that attempts to mimic Unix behavior when an open file is deleted by changing unlinks of open files into renames. Without more details, I can't say whether Dave was experiencing the same thing. If so, it is more likely due to a change in file usage than a change in the server OS.
--bob--
I've started seeing exactly this sort of failure in rm -rf's as of 5.3.2D3.
rm: Unable to remove directory foo/bar/baz/gorp: File exists rm: Unable to remove directory foo/bar/baz: File exists rm: Unable to remove directory foo/bar: File exists rm: Unable to remove directory foo: File exists
Someone asserted that these files were probably open. But they're not... or at least they're no more or less likely to be open than any of the other files I have rm -rf'ed with no problem in the past.
The problem is non-deterministic. Re-running the rm -rf does help, but of course having to repeatedly re-issue rm commands as root does pose quite a new set of problems. :-\
Brian
On Mon, 8 Nov 1999, Brian Rice wrote:
I've started seeing exactly this sort of failure in rm -rf's as of 5.3.2D3.
rm: Unable to remove directory foo/bar/baz/gorp: File exists rm: Unable to remove directory foo/bar/baz: File exists rm: Unable to remove directory foo/bar: File exists rm: Unable to remove directory foo: File exists
Since my original mail I've discovered that the problem is also occuring on another filer which is still running 5.2.2P1. I'm now wondering if it's more related to running Solaris 2.7 - the Sun system on which we now regularly see the problem was upgraded to 2.7 a few weeks ago.
We specifically see the problem removing old, unused user home directories - no chance of any files being open.
Dave Atkin ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk ------------------------------------------------------
Since my original mail I've discovered that the problem is also occuring on another filer which is still running 5.2.2P1. I'm now wondering if it's more related to running Solaris 2.7 - the Sun system on which we now regularly see the problem was upgraded to 2.7 a few weeks ago.
My admin hosts, on which I see the problem, remain at 2.5.1 and even 2.5 (horrors).
Brian
If you are using this with cifs I would try turning the oplocks of on the the qtree and also under options. This seems to help with this problem.
Travis A. Zadikem Senior Network Engineer Aztek Engineering, Inc.
A mind is like a garden it only grows when fed and watered correctly. Brian Rice wrote:
I've started seeing exactly this sort of failure in rm -rf's as of 5.3.2D3.
rm: Unable to remove directory foo/bar/baz/gorp: File exists rm: Unable to remove directory foo/bar/baz: File exists rm: Unable to remove directory foo/bar: File exists rm: Unable to remove directory foo: File exists
Someone asserted that these files were probably open. But they're not... or at least they're no more or less likely to be open than any of the other files I have rm -rf'ed with no problem in the past.
The problem is non-deterministic. Re-running the rm -rf does help, but of course having to repeatedly re-issue rm commands as root does pose quite a new set of problems. :-\
Brian
-- Travis A. Zadikem Senior Network Engineer PH: (303)-415-6175 Fax: (303)-786-9190
A mind is like a garden it only grows when fed and watered correctly.
-
Brian Rice -
Dave Atkin -
Jason E . Murray -
Jay Orr -
Robert English -
Travis Zadikem