How to detect if a special file is running or not with powershell? - powershell

Question

Get-Process only gives the result if a notepad or exe file is running but I want to know if a specific file (index.txt) which is in some folder is running or not in powershell

Answer 1

You can use the mainWindowTitle method and then select the names of the processes running. Something like this -
get-Process notepad | where-Object {$_.mainWindowTitle} | Select-Object id, name, mainwindowtitle
This will give you the list of notepads processes running, and if you find your file index.txt under the MainWindowTitle header then, you can confirm that your file is running indeed.

Answer 2

Get-Process gets all running processes.
A text file is not a process, it of course is an object opened by / in a process (whether PS started it or not), notepad, winword, etc...
PS can be used to start a process, say notepad, but PS does not own it, the exe does.
So, a file, in the context you are asking, is never running in PS, the process (running on your system) can be looked up using Get-Process (or the old Tasklist tool which Get-Process replaces) as well as the path information of the running process.
Start notepad manually and open a text file.
Run Get-Process and ask for all values of the notepad process.
You will see the Get-Process brings back a whole lot of info for you to select from.
Note that it is the MainWindowTitle, which shows what file the Notepad process has open, but no where in this results does it say where that file (path) is ran from.
Get-Process Notepad | Select-Object *
Name : notepad
Id : 20516
...
Path : C:\WINDOWS\system32\notepad.exe
Company : Microsoft Corporation
CPU : 2.515625
ProductVersion : 10.0.17134.1
Description : Notepad
Product : Microsoft® Windows® Operating System
__NounName : Process
...
MainWindowTitle : news-stuff.txt - Notepad
MainModule : System.Diagnostics.ProcessModule (notepad.exe)
...

Answer 3

Note:
This answer tells you if a given file is currently held open by someone.
If you also need to know who (what process) has it open, see the answers to this related question, but note that they require either installation of a utility (handle.exe) or prior configuration of the system with administrative privileges (openfiles)
If you want a conveniently packaged form of the technique presented in this answer, you can download function Get-OpenFiles from this Gist, which supports finding all open files in a given directory [subtree].
Files, unlike processes, aren't running, so I assume that you meant to test if a file is currently open (has been opened, possibly by another process, for reading and/or writing, and hasn't been closed yet).
The following snippet detects if file someFile.txt in the current dir. is currently open elsewhere:
$isOpen = try {
[IO.File]::Open("$PWD/someFile.txt", 'Open', 'Read', 'None').Close()
$false # file NOT open elsewhere
}
catch {
# See if the exception is a sharing / locking error, which indicates that the file is open.
if (
$_.Exception.InnerException -is [System.IO.IOException] -and
($_.Exception.InnerException.HResult -band 0x21) -in 0x21, 0x20
) {
$true # file IS open elsewhere
}
else {
Throw # unexpected error, relay the exception
}
}
$isOpen # echo the result
Note the $PWD/ before someFile.txt, which explicitly prepends the path to the current directory so as to pass a full filename. This is necessary, because the .NET framework typically has a different current directory. Prepending $PWD/ doesn't work in all situations, however; you can read more about it and find a fully robust solution here.
The code tries to open the file for reading with an exclusive lock (a sharing mode of None), which fails if the file is currently open.
Note, however, that this only works if you have permission to at least read the file.
If you don't, the test cannot be performed, and the code relays the [System.UnauthorizedAccessException] that occurred; similarly, exceptions from other unexpected conditions are relayed, such as the specified file not existing ([System.IO.FileNotFoundException]).
[System.IO.IOException] can indicate a range of error conditions (and operator -is also matches derived classes such as [System.IO.FileNotFoundException]), so in order to specifically detect sharing/locking errors, the code must test the .HResult property of the exception for containing Win32 API error codes ERROR_SHARING_VIOLATION (0x20) or ERROR_LOCK_VIOLATION (0x21).
Taking a step back: If the intent is ultimately to process the file [content] yourself, it's better not to perform a separate test beforehand, because the file may get opened again between performing your test and your subsequent attempt to open it; instead, simply try to open the file yourself and handle any failure - see this (C#-based) answer.