Disable App.config file deletion by user

Question

1.00/5 (1 vote)

See more:

I have an windows form application which uses a App.config file for storing database connection and other mailing server details. This app is to be installed on a corporate intranet network on a single tower system to which multiple users connect via Remote Desktop Connection and run the application.

This app only reads information from the config and does not write any information to it.

When i run the application first up i check if the App.config file exists in the directory where the application has been installed.

If the config file is not found application exits showing appropriate message to the user.

I want to disable the deletion of this file by any user when the application is running for the users.

As of now if the users are able to delete the config file as they know the location of the file.

The problem currently is some users don't know who but delete this file when the application is running this results in an exception being thrown and causes the application to crash.

I want to add this features in the next iteration of the application.

Just an query i have for anybody who can answer.
Doesn't the exe using the config file acquire an lock on the config file while the app is running.

Please help
Thanks in advance.

Posted 28-May-15 3:07am

Christopher Fernandes

Updated 28-May-15 3:09am

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

F-ES Sitecore · Answer 1 · 2015-05-28T03:33:00

Solution 1

Implement the appropriate security at the file level so their accounts can't delete the file. Your problem isn't a coding one but a system administration one. You can't stop people deleting files they have permissions to delete, unless you load the file and keep it locked.

Posted 28-May-15 3:33am

F-ES Sitecore

v2

Comments

Sergey Alexandrovich Kryukov 28-May-15 10:29am

The user always have more permission to delete the file than the application or its installer. The system belongs to the user, not to the application. Please see Solution 3 where I explain really working method, and only during runtime, as the inquirer wanted.

—SA

F-ES Sitecore 28-May-15 10:44am

He says people RDC in to a central PC to use it, so he *could* tie down the permissions, the file is not on the local users' machines, and I also mentioned loading\locking the file so that people can't delete it that way either.

Sergey Alexandrovich Kryukov 28-May-15 10:54am

Well, yes, I did not say that permission administration is just useless (and I did not down-voted any answer here). I just say that this is does not lie at the root of the problem.
—SA

phil.o · Answer 2 · 2015-05-28T03:53:00

Solution 2

There are several solutions:
1) First thing would be to fix the file-delete permission problem
2) You could add the content of your app.config file in the resources of your application ; if the file is not present at application startup, you can then copy it from resources to a new file, instead of presenting an error message to the user.

Posted 28-May-15 3:53am

phil.o

Comments

Sergey Alexandrovich Kryukov 28-May-15 10:29am

1) The user always have more permission to delete the file than the application or its installer. The system belongs to the user, not to the application. Please see Solution 3 where I explain really working method, and only during runtime, as the inquirer wanted.

2) Adding this content to resource would defeat the purpose: the purpose of this file is to make the user a way to edit configuration. Again, see Solution 3.

—SA

Sergey Alexandrovich Kryukov · Answer 3 · 2015-05-28T04:22:00

You can always protect any file from deletion, but only for the time it's running. It's enough to open the file and keep it open during runtime. By default, the file is open for exclusive access. The user won't be able to delete this file during run time.

But could you permanently prevent deletion of the file? No, and it would not make any sense at all. I'll try to explain why.

I don't even want to discuss the simple point that the user has a full control at the system, but your software product doesn't. The user has every right to delete any file, a part of your product or not, and face the consequences. This is the system of your user, not yours. Even if you were able to prevent deletion of any file permanently, it would fundamentally violate very basic customer's rights.

More essential point is the purpose of the App.Config. First of all, there is no such file as App.Config in the product. This file is just the development artifact, the file where you can edit default configuration. The configuration file itself which goes to the output of the build is the file which name matches the application name. If the name of the main executable module of your entry assembly is "MyApplication.exe", the configuration file goes to "MyApplication.exe.config".

The purpose of this file is to alter the configuration by the user. And the file which can be edited by the user can be deleted by the user. And, by the way, it would be good to develop the application with reasonable fallback behavior in case of the absence of the configuration file. I do understand that it can be not easy and not always possible.

—SA