2 Dec
2000
2 Dec
'00
1:53 a.m.
Neither the UNIX root user nor the NT administrator can remove the files in question when the locks occur. I believe it is a side-effect of the Filer enforcing NT locks to UNIX clients. (I don't think Netapp is necessarily doing anything wrong here. I believe this is the correct behavior in most cases.) I very commonly encounter situations on NT systems where the administrator cannot remove a file that is open, no matter who owns it.
Of course, even if root *could* remove those files as root/administrator, I'd still like a way for the files owner to be able to remove them. I'd rather not have to give my build engineers root/administrator access to my filer.
--
Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH,
GWP, MCP, MCP+I, MCSE, BFD
-----Original Message-----
From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com]
Sent: Friday, December 01, 2000 5:43 PM
To: Mike Sphar; toasters@mathworks.com
Subject: Re: Lock files
----- Original Message -----
From: "Mike Sphar" mikey@Remedy.COM
To: toasters@mathworks.com
Sent: Friday, December 01, 2000 4:11 PM
Subject: RE: Lock files
> I was about to ask a similar question actually. We keep running into
> problems where our build group can't delete a directory because someone
else
> had opened one of the files in it, and then the build automation fails.
Not
> even root can remove those files until the offending session is found and
> killed or the lock is removed.
This I don't understand. Root should always be allowed to remove
files even if they are locked. If the filer doesn't allow that, I consider
it a bug (even if it's a design choice).
Of course, NT's Administrator has different privelages. I suppose
you could enforce that on the UNIX side and require root to first
chown the files to root, and then delete them. But that would be
an optional behavior.
Bruce