4 replies to this topic

[johdaxx]

I have a simple install that needs to update locked files on a 2003 server's shared drive. The installer correctly copies the .rra temp files and lists the files to be renamed in the filesrenameoperations key, but upon rebooting the node, the files are not renamed and updated, and key is cleared as if it had successfully run.

Any suggestions?

Edited by johdaxx, 31 May 2007 - 20:46.

[Stefan Krueger]

A reboot ususally only works for local files, since it won't release any locks from processes running on other machines. Shut down all applications on all machines that lock the file, then you should be able to install even without reboot.

[Glytzhkof]

I once solved a similar problem by setting all files on the server share to be read-only. I think I had to add some extra code to set them read-write during install, but as far as I recall the read only status prevented the files from being locked by other users. I am not 100% sure if this works for all file types or for all OSs.

[johdaxx]

Oops -- It looks like I left out some significant details here -- The files in use are actually in use by the local server's services that are part of the product, not remote users, and the 'shared' drive is the drive shared between two nodes on a Windows 2003 cluster where the application's files reside for redundancy. The problem is that when I shut down the server's services, the cluster fails over to the next node. I think what's happening is that sometime in that failover, the renaming process gets lost somewhere, because of the .rra files all left over, even after rebooting.

[johdaxx]

I think I've got a solution - I was confusing stopping the services (as one would normally do on a non-cluster machine) with taking the services offline as is done with the Cluster Administrator. With the services offline, but the rest of the cluster resources running (quorum and shared drives inclusive) the files in question are not locked, and can be replaced. In many ways, the services seem to respond better to the cluster admin rather than the standard ways of talking to them...so it looks good.

Thanks very much for the responses.