Bestimmte Dateitypen auf der Festplatte auflisten, versteckte Ordner dabei auslassen.

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von Infinity.

    Bestimmte Dateitypen auf der Festplatte auflisten, versteckte Ordner dabei auslassen.

    Guten Morgen,

    ich möchte mir bestimmte Dateitypen auf der Festplatte anzeigen lassen, dazu habe ich diesen Code gefunden:

    VB.NET-Quellcode

    1. Dim Array() As String = Nothing
    2. Array = System.IO.Directory.GetFiles("C:\Users\TestUser", ".txt", IO.SearchOption.AllDirectories)
    3. For Each File As String In Array
    4. ListBox1.Items.Add(File)
    5. Exit For
    6. Next


    Ich bekomme aber immer Fehler weil er verstecke und Schreibgeschütze Ordner nicht macht. Gibt es eine Möglichkeit diese auch anzeigen zu lassen? Ansonsten wäre es doch sicher Möglich diese zu überspringen?

    LG
    YouNoob ;)

    Sieh Dir mal dies an:

    VB.NET-Quellcode

    1. Dim fi As New System.IO.FileInfo("c:\Temp\tst.jpg")
    2. If (fi.Attributes And IO.FileAttributes.Hidden) = IO.FileAttributes.Hidden Then
    3. ' File hat Attribut Hidden
    4. End If
    Bilder

    • Attribute.jpg

      24,21 kB, 784×129, 176 mal angesehen

    • Attribute2.jpg

      31 kB, 619×248, 182 mal angesehen
    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).
    Programmierfragen über PN / Konversation werden ignoriert!

    Okey danke, nur ich weiß jetzt nicht so recht wie ich das einsetzen soll, weil schon der Fehler schon in dieser Ziele:

    VB.NET-Quellcode

    1. Array = System.IO.Directory.GetFiles("C:\Users\TestUser", ".txt", IO.SearchOption.AllDirectories)
    kommt.
    Ich müsste also nacheinander jeden Ordner prüfen lassen bevor diese Zeile kommt oder versteh ich da jetzt was nicht?

    LG
    YouNoob

    Probier es mal so:

    VB.NET-Quellcode

    1. Dim fi As System.IO.FileInfo
    2. For Each file In System.IO.Directory.GetFiles("C:\Users\TestUser", ".txt", IO.SearchOption.AllDirectories)
    3. fi = New System.IO.FileInfo(file)
    4. If (fi.Attributes And IO.FileAttributes.Hidden) = IO.FileAttributes.Hidden Then
    5. ' File hat Attribut Hidden
    6. End If
    7. Next
    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).
    Programmierfragen über PN / Konversation werden ignoriert!

    An dieser Stelle wäre ein Try/Catch-Block sinnvoll, der den Fehler abfängt.

    VB.NET-Quellcode

    1. Try
    2. 'Hier dein Code
    3. Catch ex As UnauthorizedAccessException
    4. 'Hier evtl. in einer Liste die Dateien abspeichern, auf die du keinen Zugriff hattest.
    5. End Try


    Evtl. ist es aber besser statt Directory.GetFiles mit SearchOption.AllDirectories aufzurufen selbst alle Unterverzeichnisse reskuriv zu durchsuchen, wenn der Fehler schon bei Directory.GetFiles auftritt.

    Infinity schrieb:

    An dieser Stelle wäre ein Try/Catch-Block sinnvoll, der den Fehler abfängt.

    Schlimmer geht's immer. :D
    Wenn ein Verzeichnis im nicht erlaubten Gereich liegt, solltest Du das vorher wissen und Dich mit den erforderlichen Rechten bestücken: Administratorrechte, die kannst Du Dir beim Start des Programms holen. Wurde im Forum beliebig oft beschrieben.
    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).
    Programmierfragen über PN / Konversation werden ignoriert!

    nö. es gibt versteckte System-Ordner, die darf nichtmal Admin.

    In RecursiveFileSearch catche ich auch das UnAuthorisized-Dings.
    @TE: sollte prinzipiell für dich verwendbar sein - das sammelt halt alle Directories und alle Files in 2 verschiedene Listen.
    Was im einzelnen gesammelt wird (oder nicht) sollte man eiglich mit wenigen Zeilen an besondere Anforderungen anpassen können.

    Ich finde die Verwendung von Try-Catch an dieser Stelle nicht schlimm. Auf diese Weiße kann man ganz bequem feststellen, was bei einem Dateizugriff nicht funktioniert hat:

    VB.NET-Quellcode

    1. Dim File As FileStream
    2. Try
    3. File = New FileStream(...)
    4. Catch ex As FileNotFoundException
    5. 'Nicht gefunden
    6. Catch ex As ArgumentException
    7. 'Pfad ist ungültig
    8. Catch ex As NotSupportedException
    9. 'Dateisystem nicht unterstützt
    10. Catch ex As UnauthorizedAccessException
    11. 'Zugriff verweigert
    12. Finally
    13. If File IsNot Nothing Then File.Dispose()
    14. End Try


    Die UnauthorizedAccessException kann auch auftreten, wenn man Adminrechte hat. Die Datei kann schließlich auch von einer anderen Anwendung benutzt werden bzw.
    es gibt versteckte System-Ordner, die darf nichtmal Admin.

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

    Infinity schrieb:

    Auf diese Weiße kann man ganz bequem feststellen, was bei einem Dateizugriff nicht funktioniert hat
    Um das festzustellen brauchst du keinen TryCatch.
    Bei TryCatch besteht im Gegenteil grade die Gefahr, dass die Unfallursache nicht erkannt wird.

    Wassichhalt in TryCatch ist ein heißes Eisen ausführlich ausführe: Erst die Ersatz-Handlung programmieren, dann den TryCatch hinschreiben - niemals andersrum.
    (Und bei Unauthorisized ist die Ersatzhandlung eben: nichts tun, aber bei allen anderen Exceptions muß da was kommen bereits vorher da sein, und zwar was solides)

    Das man eine Ersatzhandlung braucht ist logisch, sonst mach Try-Catch keinen Sinn. Aber das sollte klar sein. Ich habe z. B. ein Programm, das bei Unauthorisized den Dateipfad in eine Liste schreibt, damit später nachvollzogen werden kann, auf welche Dateien es keinen Zugriff gab. Das ganze war ja nur als Schema gedacht.

    Um das festzustellen brauchst du keinen TryCatch.

    Natürlich würde der Debugger anhalten bzw. eine für den normalen Anwender nicht hilfreiche Fehlermeldung erscheinen. Allerdings ist das in der Regel nicht die Reaktion, die ich von einem fertigen Programm erwarte. Wenn man vorher weiß, dass ein Fehler auftreten kann, kann man meiner Meinung nach auch versuchen, diesen Fehler zu behandeln - genau dafür wurde Try-Catch gemacht. Und das weiß man beim Konstruktor der FileStream-Klasse auch, schließlich stehen alle möglichen Exceptions, die auftreten können auf MSDN.

Facebook
Telefonspende