On 04/07/98 09:49:22 you wrote:
Is this indeed proper bahavior? If so, is there a "Big Hammer" mode we can use to break locks if needed?
This doesn't directly answer your question but I did want to throw something out...
My view is that both root under UNIX and Administrator under NT should count as "Big Hammer". That is, these two should be able to override any and all locking behavior that would prevent an action.
However, I believe there are some things that even NT won't let the Administrator do, so I can see how for the purposes of emulation you would follow the same rules.
Under UNIX, though, root has always been able to do just about anything. The problem arises when an NT user has a file locked and in use and root on a UNIX box wants to delete that file. The answer is you can't do it. I think the same is true for modification as well.
To actually break the locks, you have to log into the filer and blow away that user's session. This just seems needlessly cumbersome. Assuming most environments have one with root access to the filesystem also having access to the filer, you are ultimately not "preventing" any behavior... you're just making it harder for the administrator. In other words, that UNIX rm should result in that CIFS user being logged out if need be.
Does anyone out there really desire to have an environment where even root can't blow such things away? If so, then perhaps this should be an option, but I would believe this group to be in the minority.
Bruce
On Tue, 7 Apr 1998 sirbruce@ix.netcom.com wrote:
Under UNIX, though, root has always been able to do just about anything. The problem arises when an NT user has a file locked and in use and root on a UNIX box wants to delete that file. The answer is you can't do it. I think the same is true for modification as well.
my 10p-worth: i think this is another switch that should get included under the "UNIX/NT file system semantics" big switch. i, too, find it very annoying that i have to track down a CIFS lock holder in order to blow away a file.
i appreciate dave's desire to completely emulate an NT file server, but would suggest this as another thing that might be disableable when the filer is in "i'm not really an NT file server, i'm a UNIX file server that can talk funny" mode.
Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C
From: sirbruce@ix.netcom.com Date: Tue, 7 Apr 1998 13:31:33 -0500 (CDT) To: jeff.stampes@xilinx.com To: toasters@mathworks.com Subject: Re: File Locking
<stuff deleted>
To actually break the locks, you have to log into the filer and blow away that user's session. This just seems needlessly cumbersome. Assuming most environments have one with root access to the filesystem also having access to the filer, you are ultimately not "preventing" any behavior... you're just making it harder for the administrator. In other words, that UNIX rm should result in that CIFS user being logged out if need be.
Ok, I'm a network Admin in a SW development company that has a netapp on order to replace an old & creaky NT file server.
We use a product that locks files and sometimes doesn't unlock them and I have to unlock them manually.
Now I know this is our files are on a NT server, but if you fire up 'winfile' from an NT box, connect to the share on ther server, highlight the file, select properties (ALT-Enter), select 'Open By', you are given a list of users who currently have the file open AND can chuck them off.
What's the behaviour on a filer when you do the above? I hope it's the same or I'm going to have problems.
Now, on the original question from Jeff about not being able to apply patches since his QA team have the file locked.
Surely this is the required behaviour. NT would have a fit if you patched a DLL or an EXE while it was in use.
If your QA team really want the latest build, then either copy it (or snapshot it?) to another area and let them mess with it there. Then you can patch the original.
On the SW process front, I think it's a bad idea to patch a build that has gone to QA (unless it's a really major bug), but rather you should wait for a list of bugs to come back from QA (in the meantime you can fix the bugs the developers know about but QA hasn't found yet). This allows you to track the particular builds (bugs in which builds etc) and also allows you to do a diff if a build which was working isn't anymore (oh didn't I tell you, I applied patch 501 to machine X at 1am this morning!) Of course to do the diff you need the original. Now I suppose you could do a snapshot of the files before you patch. Just my pennys worth (being there, done that, got the T shirt)
Regards, GB
-- Garrett Burke, Network Admin,Managed Solutions Corp. 32 Upper Mount St., Dublin, Ireland. burkeg@msc.ie +353-1-661-4840 A jug of wine, a loaf of bread and thou.
-
Garrett Burke -
sirbruce＠ix.netcom.com -
Tom Yates