Recently I was debugging a “poof-all-customer-data-is-gone” problem. It did not take much time to figure out that a wrong branch led to a Directory.Delete(customerRoot, true) line of code. The catastrophic line was written by a regular GUI developer. There are not many lines that can lead to such a disaster. So my question is how to prevent this particular call. (DirectoryInfo.Delete() is the second one).
Here is my prioritized list of possible solutions
- Compilation error with no third parties altering a build process
- Run-time interception with no third parties
- Run-time interception with third party (no altering a build process)
- Compilation error with third party (I guess PostSharp will do it)
- Educational seminar for GUI developers about how customers love their data
Any other idea?
I will mention that our system has a dedicated service (validated and logged) for file/folder delete.
To “intercept” the call at runtime, you can use the FileSystemWatcher class, but it wont actually prevent the deletion, just let you know it’s happened. Preventing the actual deletion is a lot trickier. Windows does not offer Linux’s ptrace functionality, so you cannot intercept the system call itself (there is an article about that here but the usability is fairly limited from what I can tell). What others suggest – setting access rights and trust levels – might work, but when you do actually need to delete something and your “deletion service” is just a wrapper around the .NET methods, you will prevent that from working, too.
The other option is to go for third party tools and check this at compile time – this question has just what you need for that, including examples, and there’s a lot more tools that can do this (I only use Resharper, but I would imagine it can accomplish the task as well).
However, I dont think thats the point here. Your dev made a mistake, it whacked some customer data and nobody’s happy about that. It doesnt mean you need to make a system-wide rule of it and enforce that rule, it means the dev should have tested his or her code better and/or should have used the deletion service you mention (whatever that is). No matter how hard you try, you cant prevent people from doing stupid things. You dont want to spend time and money making fortifications around the Directory.Delete() method only to find out that someone else made a different silly mistake and this particular thing will never be an issue again. Unless problems like this (misusing Directory.Delete() ) are prone to happen more than usual in your system, let it go, concentrate on other things.