This problem crops up every now and then at work. Our build machine can have it's files accessed via a normal windows file share. If someone browses a folder remotely on the machine, and leaves the window open overnight, then the build fails (as it has done now). The explorer window left opened points at one of the sub folders in the source tree. The build deletes the source, and does a clean checkout before building. The delete is failing.
Right now, I'd like to get the build to work. I'm logged in from home, and I'd rather not reboot the build machine. I'm unable to get hold of the person whose machine is looking and the files, and I can't remotely reboot their machine.
When a windows share has a lock, the locking process is System, so I don't think I can kill it, as with normal locks.
Does anyone know a way to release the lock on a shared folder without having to reboot the machine?
If you are admin on the server sharing the file over the network, you can use the Windows in-built feature:
Start → My Computer → Right-click → Manage gets you to the Computer
Management console
In the left nav, navigate to Systems Tools → Shared Folders
You can view Shares, Sessions & Open Files here. This allows you to find out who has opened which files from which workstations.
Right-click on an item in the list to be able to remove the file lock.
Hope this helps.
Found a solution.
Find the process using Process Explorer:
Download and extract procexp.exe
In Process Explorer use the "Find Handle or DLL..." command from the "Find" menu
Enter in the name of the directory which is having trouble deleting
A list of open files which match that name should be shown. Take some guesses and find which one is failing to be deleted. If the file is locked by a windows share, the process holding the file will be System
Note down the directory which was left open
Download and install the Unlocker (Warning: Link removed, as it contains malware)
Install Unlocker, disabling the option for Explorer extensions and other junk
Unlock the directory
Open up a cmd window, and navigate to C:\Program Files\Unlocker
From the cmd window, run Unlocker.exe "the-path-to-the-locked-folder"
A dialog will pop up confirming the lock release. Use the unlock button to unlock the file
Now the directory should be unlocked, and can now be deleted.
Try Process Hacker:
https://wj32.org/processhacker/
Process hacker is like Process Explorer on steroids.
To find the offending process, press CTRL+F or click the "Find Handles of DLLs" button and search for the file name.
Once you find the file in the find handles dialog, you can simply right click the file there and choose "close". (at least for v2.39.124)
Older versions had a "terminator" option in the context menu of the process.
Right click on the offending process --> Miscellaneous --> Terminator --> Select termination techniques. Note that some are possibly dangerous and may have unintended consequences.
I've had similar problems, and none of these suggestions I've seen above look suitable for automated overnight builds (as the original poster implied) because they all require manual effort to hunt down and kill the locks.
The only method I've tried that seems to work reliably is to remove the share itself, make the build, then add the share back. Here's one way of removing the share automatically:
D:\Projects>net share Projects /DELETE /Y
Users have open files on Projects. Continuing the operation will force the files closed.
Projects was deleted successfully.
(NOTE: Creating the share again automatically can be a pain if the privilege groups you need to give it are messy.)
The way i do it is by using both OpenFiles.exe and Handle.exe
You can run them in any order and you will have your resource fully unlocked.
OpenFiles: to disconnect File Sharing sessions
Handle.exe: to release any open handles (don't try to close handles belonging to pid4, since that's the system process)
You can automate this by using powershell, batch, or any language of your choice.
Another option is, starting from Windows Vista, to use the Windows tool built into the system:
monitor resources: perfmon.exe /res
Extracted from: Http://www.sysadmit.com/2017/06/windows-how-to-know-that-process-has-open-a-file.html
Related
I tried using the command lines but to no avail, as I encountered the error "Permission Denied", even after taking ownership of the folder, etc.
I would like to add if you would like to reserve the possibility to roll back to a previous version of Windows, then please do not attempt this folder removal, otherwise all records of your previous Windows will remain after the removal.
This post is for an emergency fix in the case the existence of your "Windows.old" file may cause problems in some scenarios.
There are several steps to accomplish the task:
Press Windows key + R to open up a Run command in the search bar right next to the Windows icon. Then, in the Run command, type “ms-settings:storagesense” and hit Enter to open the Storage screen.
On the right side under "Local Storage", click on the C drive (or the drive letter that holds your Windows files) concerned.
Choose "Temporary files".
Then choose to remove "Previous version of Windows" along with any other options you desire.
Click on "Remove" files.
Check that the "Windows.old" folder has indeed been removed from your C drive.
I am attempting to open a .MSI installer package file to modify it. Whenever I try to open it, it opens in read-only mode. I see this with Orca, with InstEd, or when opening the file directly via code:
`MsiOpenDatabase()` (ERROR_OPEN_FAILED with MSIDBOPEN_DIRECT or
MSIDBOPEN_TRANSACT persistence modes).
The file itself does not have the read-only attribute set (in fact, has no attributes set)
I am using an account with Administrators group access
As far as I can tell, no other process has the file open
No installs are in progress or suspended
I can copy the file to another location, and open it read/write there. But the original, I cannot touch
Thanks in advance for your help.
My guess is that this is caused by one of the following factors:
Custom NTFS access rights - defined for the file in its security descriptor
The file might be "blocked" - marked with a special flag after being downloaded via Internet Explorer.
The resolution for the latter is to right click the file and select properties and click the unblock button at the bottom of the property page and pressing OK.
The resolution for custom NTFS rights are done in a similar way by going into the security
tab of the property page for the file, but it is easier just to copy and paste the file and use the fresh copy with the default security.
Found it.
#Glytzhkof, you almost had it but there's a detail I did not know about, and left out. This is a package that lies in a folder under "access protection" by my system's anti-virus program: a filesystem hook that blocks modification of critical system and AV files. Turn off access protection temporarily, and the file is wide open.
Fortunately, one of my teammates had some experience with this, and suggested I try it. Bingo.
Thanks, all.
What I have done to get it working was to create first a backup of the MSI file, and then open that backup. It worked for me
Try to close/kill processes that might interfere, for example:
Other running Install shield instances
Installshield updater
Installshield licensing service
Antivirus
When deleting a folder that contains a file that is in use, it is common to see the following Windows 7 message,
"The action can't be completed because the folder or a file in it is open in another program."
I commonly have 10-20 programs open, 30-40 folders open, etc. In short, I have many executables running and many windows explorers open.
Does anyone know a simple trick to determine which program is using the file?
Does anyone know a simple trick to determine which file is blocking the delete operation?
This information would be highly useful to display in the Windows 7 'folder in use' dialog, but it is missing.
Consequently I have to close many of my open applications and folders to complete the delete operation. This is annoying because I have to re-open them after deleting them.
Have you seen this other question or this one?
I use to run ProccessExplorer and Find for the blocked folder.
Closing the application Malwarebytes allowed me to delete what I needed to via Windows Explorer.
In matlab, I used a windows standalone application. There is a line in this application that writes a file in C:\...\...\. When I run the output exe file produced from this windows standalone application, the exe doesn't write in C:\...\...\ neither tells me that there is a security issues in that partition. All the execution does is nothing. But, when I right-click and run the exe as administrator, it runs correctly.
I want to do it without right-click and run as administrator. Are there is a command in matlab that can do that?
If you create a shortcut to your application, you can go to the Properties of the shortcut, click on Advanced in the Shortcut tab, and select "Run as administrator". That way, whenever you start the application from the shortcut it will be run as an administrator.
(Disclaimer: applications really shouldn't "foul their own nest" by writing into Program Files. This is bad design.)
Starting from Vista, unprivileged processes are not allowed to write to protected folders such as Program Files, because Program Files is designed to store code and not data. However, since this limitation has not been enforced in XP, MS has provided a backward-compatibility hack in the form of Virtual Store. Now, when a program tries to write to protected folder, its output is being redirected into a dedicated folder. This way, the program still "thinks" it writes to its usual location, while in fact it writes to an unprotected location. However, when you later check the Program Files location, you might not see the file - because it's not really there.
You can find more details here: User Account Control Data Redirection.
If you are administrator, add full control permission for your username to the destination folder. You do that by right clicking on the folder, going to properties and then security tab. Then edit and add you username with Full Control rights. Then you don;t have to run the the program as an administrator.
There is no way you can elevate a process once it is started, so Matlab cannot possibly have a command for that. Just running Matlab elevated.
I want to known who is locking a file on a network share.
Here is the problem : the network share is on a NAS, so I can't log on. I need a tool to find out remotely who is locking the file. It is not practical to reboot the NAS every time, because there are several users.
Handle.exe, Process Explorer and PsFile seems to be limited to files on the local machine, so they don't work for me.
Just in case someone looking for a solution to this for a Windows based system or NAS:
There is a built-in function in Windows that shows you what files on the local computer are open/locked by remote computer (which has the file open through a file share):
Select "Manage Computer" (Open "Computer Management")
click "Shared Folders"
choose "Open Files"
There you can even close the file forcefully.
On Windows 2008 R2 servers you have two means of viewing what files are open and closing those connections.
Via Share and Storage Management
Server Manager > Roles > File Services > Share and Storage Management > right-click on SaSM > Manage Open File
Via OpenFiles
CMD > Openfiles.exe /query /s SERVERNAME
See http://technet.microsoft.com/en-us/library/bb490961.aspx.
PsFile does work on remote machines. If my login account already has access to the remote share, I can just enter:
psfile \\remote-share
(replace "remote-share" with the name of your file server) and it will list every opened document on that share, along with who has it open, and the file ID if I want to force the file closed. For me, this is a really long list, but it can be narrowed down by entering part of a path:
psfile \\remote-share I:\\Human_Resources
This is kind of tricky, since in my case this remote share is mounted as Z: on my local machine, but psfile identifies paths as they are defined on the remote file server, which in my case is I: (yours will be different). I just had to comb through the results of my first psfile run to see some of the paths it returned and then run it again with a partial path to narrow down the results.
Optionally, PsFile will let you specify credentials for the remote share if you need to supply them for access.
Lastly, a little known tip: if someone clicks on a file in Windows Explorer and cuts or copies the file with the intent to paste it somewhere else, that act also places a lock on the file.
If its simply a case of knowing/seeing who is in a file at any particular time (and if you're using windows) just select the file 'view' as 'details', i.e. rather than Thumbnails, tiles or icons etc. Once in 'details' view, by default you will be shown;
- File name
- Size
- Type, and
- Date modified
All you you need to do now is right click anywhere along said toolbar (file name, size, type etc...) and you will be given a list of other options that the toolbar can display.
Select 'Owner' and a new column will show the username of the person using the file or who originally created it if nobody else is using it.
This can be particularly useful when using a shared MS Access database.
The sessions are handled by the NAS device. What you are asking is dependant on the NAS device and nothing to do with windows. You would have to have a look into your NAS firmware to see to what it support. The only other way is sniff the packets and work it out yourself.
Partial answer: With Process Explorer, you can view handles on a network share opened from your machine.
Use the Menu "Find Handle" and then you can type a path like this
\Device\LanmanRedirector\server\share\
sounds like you have the same problem i tried to solve here. in my case, it's a Linux fileserver (running samba, of course), so i can log in and see what process is locking the file; unfortunately, i haven't found how to close it without killing the responsible session. AFAICT, the windows client 'thinks' it's closed; but didn't bother telling the fileserver.
Close the file e:\gestion\yourfile.dat, open by any user (/a *)
openfiles /disconnect /a * /op "e:\gestion\yourfile.dat"
more in:
http://dosprompt.info/commands/openfiles.asp