Größe von Dateien und Ordnern ermitteln (keine Zugriffsberechtigung)

  • VB.NET
  • .NET 4.5

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von VaporiZed.

    Größe von Dateien und Ordnern ermitteln (keine Zugriffsberechtigung)

    hi, ich möchte mit meinem Programm die Speichergröße von bestimmten Ordnern ermitteln. bsp.: (C:\Users\) funktioniert auch soweit. das Problem sind die Zugriffsberechtigung.
    wenn ich den Benutzer durschuche wird mir bei 90% der unterordnern der zugriff verweigert. bei den restlichen 10% wird mir nach dem durchlauf die Speichergröße auch angezeigt.

    wie bekomme ich es hin die Zugriffberechtigung zu bekommen um alle Ordner durchsuchen zu lassen? habe im app.manifest auch schn den eintrag geändert:

    VB.NET-Quellcode

    1. <requestedExecutionLevel level="highestAvailable" uiAccess="false" />


    funktioniert aber dennoch nicht.


    danke im voraus :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „user2100“ ()

    @user2100 Um das fix nachzuvollziehen, poste mal fix den elevanten Code.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    hier der code:

    VB.NET-Quellcode

    1. MessageBox.Show(GetIdealSi(GetFolderSize("C:\Users")))


    VB.NET-Quellcode

    1. Function GetFolderSize(ByVal path As String) As Long
    2. GetSize(path)
    3. Return si
    4. End Function
    5. Dim si As Long = 0
    6. Sub GetSize(ByVal path As String)
    7. Try
    8. Dim di As New IO.DirectoryInfo(path)
    9. For Each file As IO.FileInfo In di.GetFiles
    10. si += file.Length
    11. Next
    12. For Each dire As IO.DirectoryInfo In di.GetDirectories
    13. GetSize(dire.FullName)
    14. Next
    15. Catch ex As Exception
    16. MessageBox.Show(ex.Message)
    17. End Try
    18. End Sub
    19. Function GetIdealSi(ByVal bytes As Long) As String
    20. Select Case bytes
    21. Case Is > (1024.0 * 1024.0 * 1024.0 * 1024.0)
    22. Return CStr(bytes / 1024 / 1024 / 1024 / 1024) + "TB"
    23. Case Is > (1024.0 * 1024.0 * 1024.0)
    24. Return CStr(bytes / 1024 / 1024 / 1024) + "GB"
    25. Case Is > (1024.0 * 1024.0)
    26. Return CStr(bytes / 1024 / 1024) + "MB"
    27. Case Is > 1024.0
    28. Return CStr(bytes / 1024) + "KB"
    29. Case Is < 1024.0
    30. Return CStr(bytes) + "B"
    31. Case Else
    32. Return CStr(bytes) + "B"
    33. End Select
    34. End Function
    Ich tipp auf Z#9 oder #12, da UnauthorizedException. Dazu gibt es schon mehrere Ansätze im Forum, einer davon ist hier zu finden.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    @user2100 Das sollte so aussehen:

    VB.NET-Quellcode

    1. Dim files() As String = Directory.GetFiles(path, "*.*", SearchOption.TopDirectoryOnly)
    2. ' oder
    3. Dim files() As String = Directory.GetFiles(path, "*.jpg", SearchOption.TopDirectoryOnly)

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    sorry ich hab den fehler bereits gefunden

    hab jetzt aber nen anderes Problem:
    während des vorgangs kam folgende meldung von VS2017

    VB.NET-Quellcode

    1. Assistent für verwaltetes Debuggen "ContextSwitchDeadlock"
    2. Nachricht = Assistent für verwaltetes Debuggen "ContextSwitchDeadlock"
    3. : "Die CLR konnte 60 Sekunden lang keinen Übergang vom COM-Kontext
    4. 0xb95c28 zum COM-Kontext 0xb95b70 durchführen. Der Thread, der Besitzer
    5. des Zielkontexts/-apartments ist, wartet entweder, ohne Meldungen zu
    6. verschieben, oder verarbeitet eine äußerst lang dauernde Operation, ohne
    7. Windows-Meldungen zu verschieben. Eine solche Situation beeinträchtigt
    8. in der Regel die Leistung und kann sogar dazu führen, dass die Anwendung
    9. nicht mehr reagiert oder die Speicherauslastung immer weiter zunimmt.
    10. Zur Vermeidung dieses Problems sollten alle STA-Threads
    11. (Singlethread-Apartment) primitive Typen verwenden, die beim Warten
    12. Meldungen verschieben (z. B. CoWaitForMultipleHandles), und bei lange
    13. dauernden Operationen generell Meldungen verschieben."
    Jep. Wenn man solch einen aufwendigen Vorgang nicht nebenläufig macht, geht der Compiler bzw. Windows nach ner Minute davon, dass das Programm sich aufgehangen hat, da das Pogramm keine Nachrichten in der Message queue mehr verarbeitet. Arbeite mit Async/Await und die Sache ist gegessen. Oder kürze die Suchdauer, indem Du nur einen bestimmten Teil bzw. in einer bestimmten Tiefe suchst. Aber Option A ist grundsätzlich besser.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.