CODEWITHSUNDEEP
c#.netwindowsmultithreading
Malfist
Malfist

Reputation: 31795

System Wide persistent storage?

My program starts a process and I need to make sure it is killed before I can run the program again. To do this, I'd like to store the start time of the Process in something like a mutex that I could later retrieve and check to see if any process has a matching name and start time.

How could I do this? I don't really want to stick anything on the harddrive that will stick around after the user logs out.

For reference I'm using C# and .NET

Upvotes: 1

Views: 370

Answers (2)

RossFabricant
RossFabricant

Reputation: 12492

You want to store the process ID, not the process name and start time. That will make it simpler to kill the process. You can store the file in %TMP% so that it will get cleaned up when hard drive space is low.

C# code to kill the process looks like this: 

    int pid = Convert.ToInt32(File.ReadAllText(pidFile));
    Process proc = Process.GetProcessById(pid);
    proc.Kill();

You can find out the %TMP% directory like this: 

var tmp = Environment.GetEnvironmentVariable("TMP");

EDIT: The PID can be reused, so you will need to deal with that, too.

Upvotes: 4

Reed Copsey
Reed Copsey

Reputation: 564451

I agree with rossfabricant that the Process ID should be stored instead of a name. Process IDs are not reused until after a restart, so this should be safe.

However, I'd recommend against using the TMP environment variable for storage, and instead look at Isolated Storage. This would be more .NET oriented in terms of storage. Also, it would lower the security required to run your application.

Unfortunately, both temporary directories and isolated storage will persist after a logout, though, so you'll need logic to handle that case. (Your app can clean out the info on shutdown, however).

If you have access to the code of process you are starting, it might be better to use something like named pipes or shared memory to detect whether the application is running. This also gives you a much cleaner way to shut down the process. Killing a process should be a last resort - in general, I wouldn't build an application where the design requires killing a process if it was at all avoidable.

Upvotes: 2

Related Questions