Windows - cannot forcefully close the network file descriptor - cannot close system (Pid 4) files

Question

First, sorry for the long question, but I wanted to provide some fairly detailed information.

Description:

On Windows, it is not possible to forcefully close a file descriptor opened through a network resource. Therefore, a file that is opened through a network resource cannot be moved / renamed / deleted. I am using Win 7.

Question:

Can someone see what I'm doing wrong, or can someone confirm that this is as expected, and it is not possible to forcefully close the system file descriptors (always on pid 4, for example, related to access to network file sharing )

Background:

We have users of remote network clients that access the log file. We need to flip the log file so that it does not become too large. We cannot collapse the log file because the file is reported as being used.

Re-creating the problem:

0)

Do everything as an Administrator

1)

Create a new directory and share it

2)

Create a file in a new directory

3)

Through a file share, edit the file with something that tends to get file locks, such as MS Word. So, Start / Run, then type \ YourHostName, then select the file you created, then go to the file and edit it in Word. This should mimic the remote user / host blocking the file.

4)

List the open file descriptors, we can see 2 below

C:> handle C: \ Log \ MyLockedFile.txt

Pen v3.46 Copyright (C) 1997-2011 Mark Russinovich Sysinternals - www.sysinternals.com

System pid: 4 type: File 3E64: C: \ Log \ MyLockedFile.txt System pid: 4 type: File 5E48: C: \ Log \ MyLockedFile.txt

5)

Try to close the file descriptor, here we will see that an attempt to close the failure.

C:> handle -c 3E64 -p 4

Pen v3.46 Copyright (C) 1997-2011 Mark Russinovich Sysinternals - www.sysinternals.com

3E64: File (R--) C: \ Log \ MyLockedFile.txt Close the 3E64 handle on the system (PID 4)? (y / n) y Handle closing error: Invalid handle.

6)

List the network file files, here we will see the open network folders in the file.

C:> openfiles / query -v

INFO: the global flag of the system "maintain a list of objects" to include local open files. See Openfiles /? for more information.

Files opened remotely through local access points:

Host name identifier accessible by type #Locks Open Mode Open File (Path \ executable) 14693W7N 67109233 myuser1 Windows 0 Write + Read C: \ Log \ MyLockedFile.txt 14693W7N 495 myuser1 Windows 0 Read C: \ Log \

7)

Close / disconnect files from files, here it works

C:> openfiles / disconnect / a * / OP C: \ Log \ MyLockedFile.txt

SUCCESS: the connection to the open file "C: \ Log \ MyLockedFile.txt" is completed.

8)

The system file descriptor is still active even after it is deleted.

C:> handle C: \ Log \ MyLockedFile.txt

Pen v3.46 Copyright (C) 1997-2011 Mark Russinovich Sysinternals - www.sysinternals.com

System pid: 4 type: File 3E64: C: \ Log \ MyLockedFile.txt

9)

File cannot be moved / renamed as it is still in use

C:> move C: \ Log \ MyLockedFile.txt C: \ Log \ MyLockedFile.txt.newName The process cannot access the file because it is being used by another process. Moved 0 files.

Answer 1

Just publish as an answer, because I saw that this question hangs around without an answer (heh, by holy chance, EXACTLY one year?)

Firstly, there is a really interesting discussion on this topic here (about NTFS, I suppose). If you read the link above, you can get good hints on why some pens seem to “hang” forever, and why “force closing” is not a good idea.

The reason that "handle -c" returned an invalid descriptor error may have something to do with running the "descriptor" locally and remotely, i.e. on the machine to which the network drive is physically connected (?)

For my own purposes and in my own script, I ended up remotely closing the handle (just because I wanted to quickly and dirty close it) using the Sysinternals tools you mentioned, namely "psexec" and "handle" (no user need to be specified and password, given that I am registered as an administrator role, I think):

rem To list the open handles psexec \\someserver -c handle /accepteula some_filename rem To force close a particular handle psexec \\someserver -c handle /accepteula -c 3F9C -p 4 

But when I ran the descriptor command again, there were no results (without open descriptors), the folder that I was trying to delete is still locked. After some time (I also tried to disconnect from the network resource in question using "net use f: / delete" to no avail, because "the active process was accessing it"). I found out that my own local machine was still keeping open handles to this directory - and in fact the handles that I forced to close remotely were from my own machine. I closed them without problems using the Process Explorer GUI, which should be equal to using "handle" from the command line. After that, you can delete this folder.

Answer 2

Hope this can help someone?

We had a rejection of the repository, and it caused a file lock called FileLock to be locked in the Citrix profile folder for the shared account. Due to blocking, users could not run Citrix applications. I could not rename to the profile folder, because if the file is locked.

I tried the above suggestions without success. Then I found this Microsoft article: Close Locked Files This worked for the first time, very simple, almost too good to be true ... :)