2011-01-10 13 views
0

Ich habe ein Stück Code, der die DeleteFile-Methode in der Microsoft.VisualBasic.FileIO.FileSystem-Klasse (in der Microsoft.VisualBasic-Assembly) in aufgerufen um die Datei in den Papierkorb zu senden, anstatt sie endgültig zu löschen. Dieser Code befindet sich in einem verwalteten Windows-Dienst und wird auf einem Win Server 2k8-Computer (32-Bit) ausgeführt.Datei in recyclebin in csharp löschen mit VB FileSystem.DeleteFile Methode funktioniert nicht richtig

Die entsprechende Zeile:

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

Natürlich, ich habe "Microsoft.VisualBasic.FileIO verwendet;" an der Spitze der Klasse und ich verifiziert, dass die aufgerufene Methode tatsächlich in der FileSystem-Klasse in diesem Namespace ist. In der obigen Zeile beziehe ich mich auf eine lokale Variable "Datei" - das ist eine FileInfo für eine lokale Datei (zB C: \ path \ to \ file.txt), von der ich sicher bin, dass sie existiert. Die Anwendung verfügt über vollständige Kontrolle über die Datei und das Verzeichnis, in dem es sich befindet.

Das scheint ordnungsgemäß zu funktionieren, da die Datei aus dem Verzeichnis, in dem es sich befand, verschwindet. Die Datei wird jedoch nicht in dem Papierkorb angezeigt. Ich habe versucht, die C: \ $ Recycle.Bin-Ordner manuell zu überprüfen, da ich vermutete, dass der in Sitzung 0 ausgeführte Windows-Dienst dazu führen würde, dass er in einem anderen Papierkorb landete, aber alle Papierkörbe leer sind.

Hat jemand eine Ahnung, was dieses Verhalten verursacht?

Übrigens ist die Maschine definitiv nicht frei von freiem Speicherplatz auf dem fraglichen Laufwerk (oder jedem anderen Laufwerk für die Angelegenheit), und die Datei ist sehr klein (ein paar Kilobyte, so dass es nicht überschreitet der Papierkorb-Schwellenwert).

+0

posten Sie bitte Ihren Code. Ich habe das in der Vergangenheit ohne Probleme gemacht. – hunter

+0

Editierte Post, um die relevante Codezeile und einige weitere Erklärungen zu enthalten. – Mels

Antwort

3

Ich nehme an, dass Ihr Dienst unter einem anderen Benutzerkonto ausgeführt wird als Ihr eigenes (oder eines der speziellen Dienstkonten).

Ich glaube nicht, dass es für einen Benutzer möglich ist, den Inhalt des Papierkorbs eines anderen Benutzers anzuzeigen - obwohl Sie einige Hinweise auf ihre Existenz im Ordner C: \ $ Recycle.Bin sehen können.

Wenn es unter einem anderen Benutzerkonto ausgeführt wird, versuchen Sie, sich mit diesem Konto beim Computer anzumelden, und überprüfen Sie dann den Papierkorb. Wenn es unter einem Dienstkonto ausgeführt wird (z. B. lokaler Dienst, Netzwerkdienst oder lokales System), wird es schwieriger.

Angesichts der Tatsache, dass die Papierkörbe getrennt sind, wie planen Sie, die Tatsache zu nutzen, dass die Datei sowieso im Papierkorb ist?

+0

Der Dienst wird als lokales System ausgeführt. Ich werde versuchen, was passiert, wenn ich die Prozessidentität in ein Konto ändere, in das ich mich interaktiv einloggen kann. – Mels

+0

Ich wusste nicht, dass es absolut keine Möglichkeit gibt, auf den Papierkorb eines anderen Benutzers zuzugreifen. Ich glaube, ich habe das einmal in der Vergangenheit getan, aber es könnte sein, dass ich mich irre oder die Isolation seitdem stärker geworden ist. Ich werde weiter untersuchen. – Mels

+0

@Mels - Ich verstehe (aus der großen vertrauenswürdigen Quelle, die Wikipedia ist), dass es zwischen 2000 und XP geändert hat.Aber es ist "Zitat benötigt". –

0

Das Problem könnte von dem Benutzer stammen, der Ihren Dienst ausführt, könnten Sie versuchen, die ausführende Benutzerrichtlinie zu ändern oder den ausführenden Benutzer zu ändern.

Wie auch immer, es könnte auch von dem Service kommen, der ohne Shell ausgeführt wird, da der Papierkorb von der Shell API abhängt. this post scheint dieses Problem zu bestätigen. Sie müssen also einen anderen Ansatz für den Zugriff auf Shell API von Ihrem Dienst verwenden.