We have a script that runs nightly on our Win2K SP4 server. (I know, we need to upgrade the server OS. We plan to do that soon.)

Sometimes the script has failed when people had left shared folders open from their desktops.

So we have used the net files and net file NNNN /close batch commands to find and close them. This has worked for us.

However as of last week, some folders were left open from a Windows 7 desktop. The script "closed" them as usual, and the log shows The command completed successfully. for each one. But the folders were apparently still open: the script's later operations on those folders failed.

This is confirmed when I log in to the Win2K server and manually close the open folders using Computer Management > Shared Folders > Open Files / Right-click > Close. When I do that, the open folders disappear from the list at first, but then when I refresh the list, those folders are back on it.

Notably, this happens with folders open in Explorer on Windows 7, but not with folders open on Windows XP, for example. If a shared folder is open in Windows Explorer on XP, and I close that folder from the server side, it stays closed. This problem also does not happen with files open in certain other apps; e.g. if I have a file open in Notepad++, and I close it on the server, it stays closed.

On the server side, I have tested this phenomenon in Win2003 Server and Win2008 Server Standard SP2. The result is the same: when you close an open shared folder from the server side, it reappears immediately (or never disappears, in the case of Win2008). But only if it's open from Windows 7; not from e.g. Win2003 Server.

So I wonder if there's been some Windows 7 update recently that causes Explorer to immediately re-open folders that have been closed by the server?

If so, what could I do about it from the server side, to keep those folders closed until our script is done running?

Thanks for any help or suggestions.


I dunno if I like this suggestion, but I'll make it anyways. What about using "net stop server" and then once the process completes "net start server"? Since the sharing services would be offline, no amount of trying on the part of the client workstations should allow it to reconnect. I don't know what other side effects this would have in your enterprise. Printers and other windows services would go offline as well, so just be forewarned.

  • Hey, I think that's a good option for us. +1. We don't use the server for print sharing anyway. And the script only runs at 10:30pm for 5 minutes. So unless a better answer shows up soon, I'll accept yours. – LarsH Oct 10 '11 at 21:46
  • 1
    What we actually did was use psfile filename -c to close the file again every time a file was found to be locked. So by doing that we avoided leaving the sharing services completely off during the time the script is running. But I still think your answer is a good one. – LarsH Dec 18 '13 at 22:13
  • That certainly seems like a more directed approach, and likely a much better fit. Glad I could help. – MikeAWood Dec 19 '13 at 8:20
  • Minor correction to my previous comment: What we actually did was use psfile filename -c to close connections to a file, every time the file was found to be locked. – LarsH Dec 19 '13 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.