如何阻止或拦截对 Directory.Delete(path, true) 的调用 [英] How to prevent or intercept a call to Directory.Delete(path, true)

问题描述

最近我正在调试一个poof-all-customer-data-is-gone"问题.很快就发现错误的分支导致了 Directory.Delete(customerRoot, true) 代码行.灾难性的一行是由一个普通的 GUI 开发人员编写的.能导致这样灾难的线路并不多.所以我的问题是如何防止这个特定的调用.(DirectoryInfo.Delete() 是第二个).

这是我列出的可能解决方案的优先列表

• 编译错误，没有第三方改变构建过程
• 没有第三方的运行时拦截
• 与第三方的运行时拦截(不改变构建过程)
• 第三方编译错误(我猜 PostSharp 会这样做)
• 面向 GUI 开发人员的关于客户如何喜爱他们的数据的教育研讨会

还有其他想法吗?

我要提一下，我们的系统有一个专门的文件/文件夹删除服务(经过验证和记录).

解决方案

要在运行时拦截"调用，可以使用 FileSystemWatcher 类，但它实际上不会阻止删除，只是让您知道它发生了.防止实际删除要棘手得多.Windows 不提供 Linux 的 ptrace 功能，因此您无法拦截系统调用本身(有一篇关于 此处，但据我所知，可用性相当有限).其他人的建议 - 设置访问权限和信任级别 - 可能会起作用，但是当您确实需要删除某些内容并且您的删除服务"只是 .NET 方法的包装器时，您也会阻止它工作.

另一种选择是使用第三方工具并在编译时进行检查 - this question 正是您所需要的，包括示例，还有更多工具可以做到这一点(我只使用 Resharper，但我想它也可以完成任务).>

然而，我认为这不是重点.你的开发人员犯了一个错误，它破坏了一些客户数据，没有人对此感到高兴.这并不意味着您需要制定系统范围的规则并强制执行该规则，这意味着开发人员应该更好地测试他或她的代码和/或应该使用您提到的删除服务(无论是什么).再怎么努力，也无法阻止别人做蠢事.您不想花费时间和金钱在 Directory.Delete() 方法周围设置防御工事，只是为了发现其他人犯了一个不同的愚蠢错误并且这个特定的事情再也不会成为问题.除非像这样的问题(滥用 Directory.Delete() )在您的系统中比平常更容易发生，否则就放手吧，专注于其他事情.

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.

这篇关于如何阻止或拦截对 Directory.Delete(path, true) 的调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！