...they have been told not to keep them active overnight. Everyone's happy with this arrangement, but you do get people just plainly forgetting.
It's only when the Python interpreter process is killed that the locks release. That means I cant restore the data without exiting the script runner. I've been trying to find a way to either run the tool on a seperate python process or somehow remove the locks but I cant seem to solve the problem. Any ideas?
Thanks for posting about the FSMGMT.MSC command. I'm been struggling with a script for a day and a half, with a rename (or copy/delete) just giving me a generic error. Tried the manual process, and even command line (DOS) delete with no luck. Thought I had it figured out this am (rebooted my machines)...started moving forward on the script, and then I ran into issues and reboots didn't work...ugh.. Thought I was the only one that would be accessing the fgdb, but with the command above, I was able to find who had a lock on the timestamps file in an otherwise deleted/empty fgdb folder. So thanks....old thread but still very helpful!
Hi All, I just asked my systems admin what he does to forcibly close files if he needs to. He told me to google PsTools. The specific tool is called psfile.exe. I use C# arcObjects to accomplish data processing automation and I was able to use this before Compacting a file geodatabase that we use in map services (always has locks). Here's an example of what I run:
// forcibly close files in WPUB so we can compact it
System.Diagnostics.Process P = new Process();
System.Diagnostics.ProcessStartInfo si = new ProcessStartInfo();
si.WindowStyle = ProcessWindowStyle.Hidden;
si.FileName = "cmd.exe";
si.Arguments = "T:\\GIS\\scripts\\PSTools\\psfile.exe \\\\gis10 F:\\gis10$\\wpub\\WPUB.gdb -c -nobanner";
si.RedirectStandardOutput = true;
si.UseShellExecute = false;
P.StartInfo = si;
Then I run the compact immediately after. It works like a charm.