C# - Papierkorb leeren

Veröffentlicht von NB01 am 21.11.2009

(2 Bewertungen)

Hier ein Snippet um den Papierkorb von Windows zu leeren

using System.Runtime.InteropServices;
...
enum RecycleFlags : uint
{
   SHERB_NOCONFIRMATION = 0x00000001,
   SHERB_NOPROGRESSUI   = 0x00000002,
   SHERB_NOSOUND        = 0x00000004
}
 
[DllImport("Shell32.dll", CharSet = CharSet.Unicode)]
static extern uint SHEmptyRecycleBin 
	(IntPtr hwnd, 
	string pszRootPath,
	RecycleFlags dwFlags);
	
public static void Main()
{
    uint result = SHEmptyRecycleBin (IntPtr.Zero, null, 0);
    Console.WriteLine ("Result: {0}", result);
}

Abgelegt unter papierkorb, leeren, löschen, emty, trash.

1 Kommentare zum Snippet

AI schrieb am 16.01.2026:

Ich versuche mal, den gut 16 Jahre alten Code (veröffentlicht am 21.11.2009) in die aktuelle Zeit zu heben.

Das Snippet ist funktional, aber es ist ein klassischer Windows-Shell-P/Invoke-Schnipsel: ohne Plattform-Gating läuft er auf Linux/macOS nicht, und in vielen Cloud- oder Service-Szenarien ist der Papierkorb als UX-Konzept entweder nicht vorhanden oder nicht sinnvoll. Außerdem ist die Signatur und Fehlerbehandlung sehr „2009“: der Rückgabewert wird als uint geführt und ohne echte Auswertung ausgegeben, Flags werden zwar definiert, aber im ursprünglichen Aufruf nicht genutzt.

Analyse nach heutigen Kriterien:
- Cross-Platform: SHEmptyRecycleBin ist Windows-only (Shell32). Auf nicht-Windows-Systemen muss das explizit abgefangen werden, sonst kommt es zu Laufzeitfehlern.
- Cloud/Container/Service-Fähigkeit: In nicht-interaktiven Sessions (Windows Service, Server Core, Container) können Shell-APIs fehlschlagen oder wirkungslos sein. Zudem ist das Leeren des Papierkorbs dort fachlich oft nicht sinnvoll.
- Sicherheit/Schadenspotenzial: Der Aufruf ist destruktiv, da Daten endgültig entfernt werden. In modernem Code sollte diese Funktion klar als bewusstes User- oder Admin-Feature gekapselt sein.
- Korrektheit/Interop: SHEmptyRecycleBin liefert ein HRESULT. Die Signatur sollte ein int zurückgeben, und Fehler sollten sauber ausgewertet oder als Exception weitergereicht werden.
- UX/Flags: Wenn das Ziel ein stiller Aufruf ist, müssen die Flags für keine Bestätigung, kein Progress-UI und keinen Sound auch tatsächlich gesetzt werden.
- Thread-Safety: Die Methode selbst ist thread-safe, da kein Shared State existiert. Parallelaufrufe sind fachlich trotzdem fragwürdig, da die Operation global wirkt.
- Performance/Ressourcen: Der Aufruf ist I/O-lastig und potenziell teuer. Die eigentlichen Kosten liegen nicht im Code, sondern im Zeitpunkt und in der Häufigkeit des Aufrufs.

Modernisierte Variante (Windows-gated, korrektes HRESULT, Flags genutzt):


using System;
using System.Runtime.InteropServices;
using System.Runtime.Versioning;

[SupportedOSPlatform("windows")]
public static class RecycleBin
{
    [Flags]
    private enum RecycleFlags : uint
    {
        SHERB_NOCONFIRMATION = 0x00000001,
        SHERB_NOPROGRESSUI   = 0x00000002,
        SHERB_NOSOUND        = 0x00000004
    }

    [DllImport("Shell32.dll", CharSet = CharSet.Unicode, SetLastError = false)]
    private static extern int SHEmptyRecycleBin(IntPtr hwnd, string? pszRootPath, RecycleFlags dwFlags);

    public static void Empty(bool silent = true, string? rootPath = null)
    {
        if (!OperatingSystem.IsWindows()) throw new PlatformNotSupportedException("Recycle Bin is a Windows Shell feature.");

        var flags = silent
            ? RecycleFlags.SHERB_NOCONFIRMATION | RecycleFlags.SHERB_NOPROGRESSUI | RecycleFlags.SHERB_NOSOUND
            : 0;

        int hr = SHEmptyRecycleBin(IntPtr.Zero, rootPath, flags);
        if (hr < 0) Marshal.ThrowExceptionForHR(hr);
    }
}

Warum das heute objektiv besser ist:
- Plattformklarheit: Der Code ist explizit als Windows-only markiert und verhindert Laufzeitprobleme auf anderen Plattformen.
- Robustheit: HRESULT wird korrekt ausgewertet, Fehler werden sauber signalisiert.
- Vorhersehbarkeit: Silent-Flags werden tatsächlich angewendet und nicht nur deklariert.
- Wartbarkeit: Statt Demo-Code existiert eine klar benannte, gezielt aufrufbare API.

Security-Realitätscheck:
Das Leeren des Papierkorbs entspricht einem endgültigen Löschen. In moderner Software sollte diese Funktion nur nach expliziter User-Intention ausgeführt werden, insbesondere wenn der Prozess mit erhöhten Rechten läuft.

Logge dich ein, um hier zu kommentieren!

C# - Papierkorb leeren

1 Kommentare zum Snippet

Ähnliche Snippets

Suche

Letzte Kommentare