1

我有一段代码调用 Microsoft.VisualBasic.FileIO.FileSystem 类（在 Microsoft.VisualBasic 程序集中）中的 DeleteFile 方法，以便将文件发送到回收站而不是永久删除它。此代码位于托管 Windows 服务中，并在 Win Server 2k8 机器（32 位）上运行。

相关线路：

FileSystem.DeleteFile(file.FullName, UIOption.OnlyErrorDialogs, RecycleOption.SendToRecycleBin, UICancelOption.DoNothing);

当然，我有“使用 Microsoft.VisualBasic.FileIO;” 在类的顶部，我验证了被调用的方法确实在该命名空间中的 FileSystem 类上。在上面的行中，我指的是一个局部变量“file”——它是一个本地文件（比如 C:\path\to\file.txt）的 FileInfo，我确信它存在。该应用程序可以完全控制文件及其所在的目录。

这似乎工作得很好，因为文件从它所在的目录中消失了。但是，该文件没有出现在回收站中。我尝试手动检查 C:\$Recycle.Bin 文件夹，因为我怀疑会话 0 中运行的 Windows 服务会使其最终进入不同的回收站，但所有回收站都显示为空。

有人知道导致这种行为的原因吗？

顺便说一句 - 机器绝对没有问题驱动器（或任何其他驱动器）上的可用空间，并且文件非常小（几千字节，所以它不超过回收站阈值）。

4

2 回答 2

4

我假设您的服务在与您自己的用户帐户（或特殊服务帐户之一）不同的用户帐户下运行。

我不相信一个用户可以查看另一个用户的回收站的内容 - 即使您可以在 C:\$Recycle.Bin 文件夹中看到它们存在的一些证据。

如果它在另一个用户帐户下运行，请尝试使用该帐户登录机器，然后检查回收站。如果它在服务帐户（例如本地服务、网络服务或本地系统）下运行，则会变得更加棘手。

鉴于回收站是独立的，您打算如何利用文件在回收站中的事实？

于 2011-01-10T14:24:41.813 回答
0

问题可能来自执行您的服务的用户，您是否可以尝试更改执行用户策略或更改执行用户。

无论如何，它也可能来自在没有 shell 的情况下执行的服务，因为回收站依赖于 shell api。这篇文章似乎证实了这个问题。因此，您需要采用另一种方法从您的服务中访问 shell api。

于 2011-01-10T14:24:45.177 回答