.NET - 从应用程序可靠地维护文件系统
我有一个混合应用程序，该应用程序在数据库和由我的应用程序维护的物理文件存储中都有数据。当我开发应用程序时，有时会遇到这样的情况：我通过应用程序从硬盘驱动器移动或删除文件，无论出于何种原因，都会出现问题并引发异常。目前我只是简单地记录下来并继续。
假设删除或移动场景，当我抛出并记录异常时，我现在有一个胭脂或可能丢失的文件占用空间，并且还可能导致应用程序内的呈现错误。除了手动维护文件系统之外，还有哪些可靠的技术可以通过应用程序维护文件系统？
我特别感兴趣的是，无论如何，如何确保我在应用程序中调用 Delete() 的文件实际上已被删除。
I have a mixed application that has data both in a database and in a physical file store maintained by my application. As I have been developing my application I have, on occasion, run into scenarios where I am moving or deleting a file from the hard drive through my application and for whatever reason something will go wrong and an exception is thrown. Currently I simply log this and move on.
Assuming the delete or move scenario, when I throw and log the exception I now have a rouge or possibly missing file taking up space and also possibly causing presentation errors within the application. Beyond manual maintenance of the file system, what are some reliable techniques for maintaining a file system from an application?
I am particularly interested in how to make sure, no matter what, a file I call Delete() on in my application is in fact deleted.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您使用的是 Vista 或更高版本，您可以使用事务性文件系统来确保您的操作原子。您可以在事务性文件系统操作中找到一些示例，其中包含一些包装纸等。
If you are using Vista or later, you can use the Transactional File System to ensure your operations are atomic. You can find some examples at Transactional File System Operations with some wrappers and the like.
由于您已经在应用程序中使用数据库，因此您可以考虑创建一个表来跟踪文件系统操作。例如，您可以创建一行，其中包含要执行的文件系统操作的详细信息，然后执行文件系统操作，成功后删除该行或在数据库中将其标记为已完成。如果您的应用程序失败和/或需要重新启动，这将提供一种简单的机制来确定哪些文件系统操作未成功完成并需要重试。
Since you are already using a database in your application, you could consider creating a table to track the file system operations. For instance you could create a row containing the details of the file system operation you are about to perform, then perform the file system operation, and upon success either delete the row or mark it completed in the database. If your application fails and/or needs to be restarted, this would provide an easy mechanism to determine which file system operations did not complete successfully and need to be retried.