Okular 10 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 Hallo Leute, ich suche eine gescriptete Möglichkeit, die Größe eines Verzeichnis' zu ermitteln - am besten per Powershell. Hat da jemand eine Idee? Okular Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 Moin, FoldSize von Manfred Paleit. Tools4Net - Skripts and .NET Tools for Administration Gruß, Nils Zitieren Link zu diesem Kommentar
Cybquest 36 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 Zu PS: Vielleicht hilft das weiter... Windows PowerShell Tip: Determining the Size of a Folder Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 Kurze Frage am Rande zu den Powershell Scripts: Was macht Powershell, wenn der Pfad länger als 256 Zeichen ist? Klappt das noch oder kommt der am Ende mit einer PathTooLongException zurück? Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 Hi, also ich habe es nicht mit dem konkreten Script von oben getestet, aber generell kann die PowerShell auch mit mehr als 256 Zeichen umgehen, das habe ich schon getestet. Da dieselben APIs benutzt werden, würde ich vermuten, daß auch das o.g. Script keine Probleme macht. Viele Grüße olc Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 Ich hatte letztens nur das Problem unter .NET. Die managed API konnte nur bis 256 Zeichen Pfadlänge, also musste ich auf den "Umweg" über die kernel32.dll ausweichen. Tolle alte C-Interfaces kommen da wieder an die Oberfläche... *grusel* Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 ...mh, interssant. PowerShell ist ja in großen Teilen .Net - von daher wundert es mich, daß ich dann keine Probleme hatte. Na mal schauen, ich check das auch noch mal ab. Kommt vielleicht auf die aufgerufene Funktion oder Methode an. Gruß olc Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 29. Januar 2009 Melden Teilen Geschrieben 29. Januar 2009 In meinem Fall war ich (bis ich auf das Problem stieß) über System.IO.FileInfo gegangen. Und der gesamte System.IO-Namespace scheint über die "begrenzte" Managed-API zu gehen. Der Umweg zur Lösung führt dann über System.RunTime.InterOpServices und die Anbindung der kernel32.dll. Gruß Carsten Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 31. Januar 2009 Melden Teilen Geschrieben 31. Januar 2009 Hallo es funktioniert weder mit .Net System.IO noch mit Comobjekten :confused: foldername="C:" for ($i = 1;$i -lt 25;$i++){ [system.io.directory]::createdirectory($foldername) $foldername=$foldername+"\123456789012345" } $foldername="C:" $fso=new-object -com "Scripting.FileSystemObject" for ($i = 1;$i -lt 25;$i++){ $foldername=$foldername+"\123456789012345" $fso.createfolder($foldername) } beide Scripte brechen ab, wenn 260 Zeichen Pfadlänge überschritten werden. Ebenso in VisualBasic. Vielleicht geht's mal mit den höheren .Net Versionen als 2.0 cu blub Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 31. Januar 2009 Melden Teilen Geschrieben 31. Januar 2009 N'Abend, da brat mir doch einer 'nen Storch - ich bin mir vollkommen sicher, daß ich es vor einiger Zeit erfolgreich getestet habe. Nach blubs Post habe ich ebenfalls noch einmal getestet - und auch den Fehler bekommen... Ich check das nochmal ab, irgendwie muß ich es ja damals geschafft haben. Sollte ich mich jedoch geirrt haben, dann entschuldigt die Verwirrung. Konnte auch nirgendwo eine Einschränkung der Aussage von der maximalen Pfadlänge finden, auch nicht in Bezug auf .NET. Naming a File or Directory (Windows) Viele Grüße olc Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 31. Januar 2009 Melden Teilen Geschrieben 31. Januar 2009 es ist auf jeden Fall eine PathTooLongException vom Framework Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 2. Februar 2009 Melden Teilen Geschrieben 2. Februar 2009 Wie hier dokumentiert, ist das Auftreten der Exception unabhängig von der Version des .NET-Frameworks. DIe Exception in der ManagedAPI ist in allen Version von 1.0 bis 3.5 implementiert. Probiert mal eine Notation mit \\?\[/Code] vor dem Pfad aus, das wäre dann der umständlichere Weg über die Implementierung der Kernel32.dll, auch wenn die selbe ManagedAPI genutzt wird. Diese reicht das dann intern weiter. Siehe auch: David L. Walker - .NET Solution Provider : PathTooLongException work around Oder man macht es dann ganz umständlich: VBnet™ Visual Basic Developers Resource Centre (so musste ich es leider machen, da ich ein paar mehr Infos über die Folder brauchte. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.