我有一段代码调用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” - 这是一个本地文件的FileInfo（比方说，C：\ path \ to \ file.txt），我确定它存在。该应用程序可以完全控制文件和它所在的目录。
当文件从它所在的目录中消失时，这似乎工作得很好。但是，该文件没有显示在回收站中。我尝试手动检查C：\ $ Recycle.Bin文件夹，因为我怀疑在会话0中运行的Windows服务会使其最终位于不同的回收站中，但所有回收站都显示为空。
有没有人知道导致这种行为的原因是什么？
顺便说一句 - 机器肯定没有超出驱动器上的可用空间（或任何其他驱动器），而且文件非常小（几千字节，因此它不会超过回收站阈值）。
答案 0 :(得分：4)
我认为您的服务是在与您自己（或其中一个特殊服务帐户）不同的用户帐户下运行。
我不相信一个用户可以查看其他用户的回收站的内容 - 即使您可以在C：\ $ Recycle.Bin文件夹中看到它们存在的一些证据。
如果它在另一个用户帐户下运行，请尝试使用该帐户登录计算机，然后检查回收站。如果它在服务帐户（例如本地服务，网络服务或本地系统）下运行，那将会更加棘手。
鉴于回收箱是独立的，您打算如何利用文件在回收站中的事实呢？
答案 1 :(得分：0)
问题可能来自执行服务的用户，您是否可以尝试更改正在执行的用户策略或更改正在执行的用户。
无论如何，它也可能来自没有shell的服务，因为回收站依赖于shell api。 this post似乎证实了这个问题。因此，您需要采用另一种方法从您的服务中访问shell api。