Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a problem with a programmable/scriptable off-the-shelf third party product that creates files that we need to post-process (move, zip, or whatever).

The product let's us run commands after it has finished creating its output, so everything is perfect, right?

Not so much, because the application still has the files "open" when calling our script, so Windows won't let me touch them or the directory they're in.

The only idea I have so far is start mystuff.bat and starting mystuff.bat with a sleep, but that opens up a can of worms with respect to error handling and such, because the server program can't know when the post-processing job has finished.

Anyone know how to solve this problem?

  • The files are written to local disk on the windows server (2008 R2).
  • Asking the software supplier to fix their program has failed so far :-(

The software is PrintNetT, a print production system, it runs as a service/daemon, processing job requests, creating directories+files, keeping them locked for the duration of the batch creating them. It runs 24/7 on a server (headless). After the batch has finished, the files are not locked anymore.

share|improve this question
You could probably script something using Handle from Sysinternals – Nifle Jun 27 '12 at 9:51
@Nifle, thanks for the handsome edit of my question. Now it is clear, concise and to the point. Still asking exactly what I wanted to ask. Thanks mate! I upvoted your comment about handle to say thanks for the cleanup of the question. – MattBianco Jun 27 '12 at 12:04

What type of "product" is this? Obviously it's software, but is it an executable? Does it have a unique process (that is to say, does it show up in the processes tab of the task manager)? If it does, that would be my first guess at your best bet of getting it "closed."

If it's not, however, what type of file is it that's running, and are you able to log off or reboot without losing whatever it was you needed from it? If so, try that, and see if that works. If not, you'll need to provide a bit more information.

share|improve this answer
I think there's also something in pstools, should you need to do command line scripting for it. – Journeyman Geek Jun 28 '12 at 11:07

You could try copying the files or archiving them (zip) with programs that do not require full read/write/delete access. I think most linux programs adapted to windows have this property. This way, you can have the files copied before the application quits, process the data, then clean up the leftovers periodically.

To see if this method works, you may try to open any file still "open" with a decent text editor, like Visual Studio, Notepad++ or Vim.

share|improve this answer
I've tried GoW and run in to same kind of locking problems. I don't think it's up to an application to decide if it may read a file or not. It must be decided by the O/S. – MattBianco Jun 28 '12 at 7:21
link is borked - use markdown for the link, rather than html for it to work properly – Journeyman Geek Jun 28 '12 at 7:22
@MattBianco: It's up to the first program that opened a file whether subsequent programs may open the file or not. The OS determines the default behavior if no preferences has been indicated. Unfortunately, Windows locks files by default (while it takes far more effort to do so under Linux). If there's absolutely no way to open the file while your application is running, either wait for the application to release the file using SysInternals handle, brute-force file lock polling (…) – Interarticle Jun 28 '12 at 7:36
Or close the file handle in the application by writing a program with detours that injects into this application: – Interarticle Jun 28 '12 at 7:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .