sirbruce wrote:

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.

I think having to take explicit action to terminate a CIFS session is preferable to blowing it away as a side-effect of a remove. I would worry about making it too easy to accidently remove something that is in use.

Garrett Burke wrote:

[deleted description of using "winfile" to close files]

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.

With currently shipping products you will have to issue the commands to do this from the filer console, a web browser, or rsh, but not using the native NT server manager tools. At the risk of bringing down the wrath of the product folks here at Netapp, I'll just say that that will be changing soon, and I think you'll like the change.

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.

Interesting you mentioned snapshot. It might be feasible to have the testers use the executables from a filer snapshot. That way you could have the live build system put things in the usual place while testing is going on. Of course, that wouldn't apply to files that need to be modified, since snapshots are read-only.

Mark Muhlestein -- mmm@netapp.com