Locking files on folder with external tools or native components - windows

Question

0.00/5 (No votes)

See more:

, +

Hi!

I'm a software developer, and i've been stuck on this problem for days, i've done so much googling but i found nothing about this....

I'll try to describe this problem as easy as i can.

I have 2 files, "f1" and "f2" into my directory "c:\foo\dir1\"
I want to avoid any possible "change" in those 2 files by any user, but NOT using any encryption.
Instead of using encryption, when the user opens "f1", i want to pop up something that says to him:

"Hello user! You cannot edit those files this way! You need to do *those things* or entry the password"

Where *those things* are accessibile only from my software, that callbacks the editor of those files, unlocking them at the beginning of editation and re-locking them at the end.
The possibility of unlocking the files with password is only a way to "emergency-unlock" those files, the user normally don't have it.

So, let's start with the questions:

1)
Does exist some native function of Windows that provides that mechanism, that i can use with (for instance) a .NET callback?
I know that the ZIPPING of the folder allows me to set a password, but i don't want to do that.

2)
If, as i think, the question 1 has no answers...
Does exist some "external tool" that i can callback into my code that can do this job? Like a "file locker" or similar?
In case of, i'd obviously prefer something freeware and with "open" license...

I hope i've been clear, despite my inaccurate English language...

Thank you.

What I have tried:

Googling
Examination of .NET native functions
Searching for external tools
Asking some programmers much more expert than me.

Posted 25-Apr-16 21:16pm

Member 12485168

Add a Solution

Comments

Tomas Takac 26-Apr-16 4:12am

Aren't you over-engineering this? What's so precious about these files? Why is it not enough to hide them away in AppData folder which should keep them safe from a generic BFU? Is this requirement based on real-life experience when users actually did this and broke your app? Maybe if they do change it there is a real need behind it and you should investigate why they edit the files directly instead of using your app. There are lots of possibilities you know. I'm just trying to figure out the background story.

Member 12485168 26-Apr-16 5:57am

Unfortunately, the answer on this question does not depend to me only on me, i work in a software house and there are some "rules" i need to follow to make the whole software work :)

One of them, is that i need to store my files in a subdirectory of the main installation directory of my software, like:
c:\mysoftware\subdirectory\
So, to answer at your first question, i can't store those files in the AppData folder.

I answer to the rest with a second, simple rule that i learned on my software-programmer experience...
"If you give a user the possibility to do something, be sure that, sooner or later, he will do it".

I'm meaning that even if the software works well, and there is NO reason to mess up with those files, some nosy users have done it.

Tomas Takac 26-Apr-16 6:30am

Fair enough re the location. But still it sounds you are trying to prevent a hypothetical situation. I mean are you sure it's worth spending time on this now?

Possible solution would be just grant read-only access to the users on that folder. Then you application needs either impersonate a different account which has write access or request admin rights via UAC.

Member 12485168 26-Apr-16 11:51am

I'm sure is worth, beacuse critical situations depending on this already happened.

By the way, maybe this is an unuseful question... But... Setting the read-only attribute does not prevent the possibility of deleting the files. Am i right?

By the way, i'll start searching right now if .NET offers some "permission-like" function that fits my needs. MAybe that's the right approach to solve this problem.

Thanks :)

Tomas Takac 26-Apr-16 14:54pm

Don't know about the read-only attribute but if users have full rights to the file they can change it back anyway. Access control is the key I'd say. Also I believe understanding why this is happening in the first place will help you find the right solution. Cheers.

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

Locking files on folder with external tools or native components - windows

Add your solution here

Preview 0

Locking files on folder with external tools or native components - windows

Add your solution here

Preview 0

Existing Members

...or Join us