I have a recurring ticket/call in my environment. We have a large Windows 2012 R2 file server that is highly utilized. I have an issue where multiple users need access to file throughout the day and user X always forgets to close it and user Y calls me to find out who is in the file, so they can talk to user X have it saved and closed so they can work with it.
If go to computer management, shared folders, and open files I can of course see the offending user and let the user needing access know who is in the file, or in the case of after hours I can close the file etc.
My ideal solution would be to fix the open file notification in office/office documents. However if there is a way the users can find this information on there own without needing to call me, or needing to give them access to computer management on the server that would be fine secondary alternative.
The user would be able to see who is locking that file. If it is working hours, I would ask the caller to call the other user instead. IT admin job is at most to find out who is using the file, up to users to call (since they all share the same file).
Without giving the user administrative privileges, not sure how you can achieve that. And I suspect the same thing is true of Process Explorer (a great tool btw, but you do need admin rights for most of that tool).
I have an issue where multiple users need access to file throughout the day and user X always forgets to close it and user Y calls me to find out who is in the file, so they can talk to user X have it saved and closed so they can work with it.
make sure to configure Powershell accordingly -v.io/powershell-commands-scripts-not-work-can-fix/ . Moreover, you can add some intelligence to that script that will make sure to automatically close sessions during after-hours, for example.
One thing that annoys me no end about Windows is the old sharing violation error. Often you can't identify what's holding it open. Usually it's just an editor or explorer just pointing to a relevant directory but sometimes I've had to resort to rebooting my machine.
I've had success with Sysinternals Process Explorer. With this, you can search to find what process(es) have a file open, and you can use it to close the handle(s) if you want. Of course, it is safer to close the whole process. Exercise caution and judgement.
Just be very careful with closing handles; it's even more dangerous than you'd think, because of handle recycling - if you close the file handle, and the program opens something else, that original file handle you closed may be reused for that "something else." And now guess what happens if the program continues, thinking it is working on the file (whose handle you closed), when in fact that file handle is now pointing to something else.
Suppose a search index service has a file open for indexing but hasgotten stuck temporarily and you want to delete the file, so you(unwisely) force the handle closed. The search index service opens itslog file in order to record some information, and the handle to thedeleted file is recycled as the handle to the log file. The stuckoperation finally completes, and the search index service finally getsaround to closing that handle it had open, but it ends up unwittinglyclosing the log file handle.
The search index service opens anotherfile, say a configuration file for writing so it can update somepersistent state. The handle for the log file gets recycled as thehandle for the configuration file. The search index service wants tolog some information, so it writes to its log file. Unfortunately, thelog file handle was closed and the handle reused for its configurationfile. The logged information goes into the configuration file,corrupting it.
Meanwhile, another handle you forced closed was reusedas a mutex handle, which is used to help prevent data from beingcorrupted. When the original file handle is closed, the mutex handleis closed and the protections against data corruption are lost. Thelonger the service runs, the more corrupted its indexes become.Eventually, somebody notices the index is returning incorrect results.And when you try to restart the service, it fails because itsconfiguration files have been corrupted.
You report the problem to thecompany that makes the search index service and they determine thatthe index has been corrupted, the log file has mysteriously stoppedlogging, and the configuration file was overwritten with garbage. Somepoor technician is assigned the hopeless task of figuring out why theservice corrupts its indexes and configuration files, unaware that thesource of the corruption is that you forced a handle closed.
Just to clarify, this is more likely to be a result of misbehaving 3rd party apps not using the CreateFile API call correctly than it is to be anything in Windows itself. Perhaps it's a consequence of the design of CreateFile, but done is done and we can't go back.
Now, if Explorer seems to be the culprit here, it may be the case that that's just on the surface, and that the true culprit is something that installs a shell extension that opens all files in a folder for it's own purposes but is either too gung-ho in doing so, or that doesn't clean up properly after itself. Symantec AV is something I've seen doing this before, and I wouldn't be surprised if other AV programs were also to blame. Source control plug-ins may also be at fault.
So not really an answer, but just some advice to not always blame Windows for what may be a badly written 3rd party program (something that can also happen on any other OS which has implicit file locking, but any unix based OS has shared access by default).
Otherwise, kill the desktop Explorer process and do what you want while it's gone. First start a copy of cmd.exe (you need a UI to do your intended cleanup). Make sure there are no non-desktop Explorers running. Then kill the last Explorer with, e.g., Task Manager. Do what you want in the command prompt. Finally, run Explorer from the command prompt, and it will become the desktop.
The above upvoted answers cover situations where a program process is holding the file handle open, which (fortunately) is most of the time - however in some cases (as is occurring on this system at the moment), the system itself holds a file handle open.
You can identify this situation by following the instructions to find the file handle holding process with process explorer above, and noting that the process name is listed as 'system', or by following the the instructions using resource monitor and noting that no image is shown having a filehandle open on your file of interest (Although obviously something does as you can't edit/delete etc the file).
I got turned on to the Free Extended Task Manager a while ago by Jeremy Zawodny's blog, and it's great for tracking down further info on processes too. +1 for Process Explorer as above, too, especially for killing processes that the standard Task Manager won't end.
There is a tool FILEMON and shows open files and handles. Its hard to keep up with its display if you watch it live, it does so quickly. But you can stop it from displaying live and you can watch all file open/write activity. Now owned by Microsoft but originally by Sysinternals
Enables an administrator to query, display, or disconnect files and directories that have been opened on a system. This command also enables or disables the system Maintain Objects List global flag.
In this example, the password is supplied on the command line. To prevent displaying the password, leave out the /p option. You'll be prompted for the password, which won't be echoed to the screen.
Enables or disables the system Maintain Objects List global flag. If used without parameters, openfiles /local displays the current status of the Maintain Objects List global flag.
Changes made by using the on or off option don't take effect until you restart the system. Enabling the Maintain Objects List global flag might slow down your system.
There are times when a file is open on a windows server and you need to view what user or process has it open. These open files can be locked and prevent users from editing, cause errors when upgrading software, hold up a reboot, and so on.
This first method is used to view open files on a shared folder. This is the best way to troubleshoot locked files that users have left open. If you need to see what process has a file open then check out method 2.
You will need to open up this console on the computer or server that has the shared folder. For example, I have a server called file1 with a shared folder named HR. To see the open files on this share I will need to open up the computer management console from the file1 server.
I cant believe in 2020 we still have to use an ancient tool in windows to drill into comp management , shares an open files to do this. Surely microsoft would have a extra feature where you just right click on file/folder to see which user is accessing the object.
I am also having an issue with Smart Sync in Windows 11. I started in Windows 11, this is not a migration issue. I have a business account with over 1 TB of data and 30k+ files. For months I have been seeing a message in my desktop client: Dropbox is experiencing some issues. Before opening online-only files and folders, right-click and choose Make available offline.
The option to make the files Online-Only again has wholly disappeared from the desktop client preferences and the menu options when I right-click on the file or folder. The only option provided is to make my files available offline.
2. Uninstalled the desktop client and reinstalled it.....also didn't fix a thing. In fact, when I reinstalled it, the set-up wizard gave me the option to start with all files as Online-Only, and the files that were set to Make Available Offline before the uninstall/reinstall still show as Offline. Meaning the uninstall/reinstall did not make them Online-Online again.
c80f0f1006