4

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

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

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

还有什么想法吗？

我会提到我们的系统有一个专门的文件/文件夹删除服务（验证和记录）。

4

3 回答 3

1

您可以将应用程序修改为不在完全信任下运行。配置限制对物理磁盘的访问的信任级别。看看 FileIOPermission。请注意，这可以针对特定位置进行配置，从而为您提供相当多的控制权。

需求概览

更新 在考虑了更多之后，我还建议进行“保姆测试”。如果您正在执行任何类型的测试，您可以添加一个测试来查看程序集中的所有类型，并检查对任何 FileSystem 方法的调用。任何此类调用都需要在白名单中，否则测试将失败。我正在做的项目使用这个，它提供了很多价值。

更新 2 有一条关于如何进行此类保姆测试的评论。基本上，您需要使用反射来获取所有方法，然后在 IL 中查找禁止调用。它听起来比它更复杂。

从程序集中提取特定 IL（.NET 中间语言）签名的机制

更新 3 还有另一种更好的方法来进行这种类型的保姆测试，它不直接涉及弄乱 IL。我在我的博客上发表了一篇文章如何做到这一点。

http://datatoknowledge.com/2012/09/10/nanny-tests/

埃里克

于 2012-06-30T23:32:19.393 回答
1

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

另一种选择是使用第三方工具并在编译时检查 -这个问题正是你需要的，包括示例，还有更多工具可以做到这一点（我只使用 Resharper，但我想它也可以完成任务）。

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

于 2012-07-01T09:37:14.350 回答
0

您可以在全局包含的命名空间中包含一个单独的目录类（和 DirectoryInfo） - 这不会阻止使用 System.IO.Directory.Delete 的人，但这是另一个可能有助于抓住它并推迟它们的想法，特别是如果您包含一个相同的虚拟函数，该函数会抛出带有消息的异常。

于 2012-06-30T22:57:57.690 回答