Bei der Installation der Arduino IDE Version 1.6.4 ist ein "rekursives" Verzeichnis erzeugt worden. libraries\libraries\libraries ... usw. Das Ende des Baumes kann ich nicht erreichen. Normales Löschen geht nicht, da "Der Ordner enthält Namen die für den Papierkorb zu lang sind"; ja welches Wunder. Wie kann ich dieses leere Verzeichnis mit seinen gesamten Unterordnern löschen ?
:
Bearbeitet durch Admin
Achim Hensel schrieb: > CTRL-DELETE im Explorer? > DEL auf der Kommandozeile? nochgeschaut: Es ist Shift-Entfernen
Remove kenne ich nur von UNIX. Na, ja wenn es denn auch unter Windows 8.1 funktioniert, umso besser.
Was muss ich dafür ausführen bzw. wie gebe ich es ein ? Da gab es doch dieses Dingsbums-Eingabefenster. Ausführen ???
Hans-werner M. schrieb: > Da gab es doch dieses Dingsbums-Eingabefenster. > Ausführen ??? Start->Ausführen->Command in das Fenster eingeben.
Warum nicht die Lösung von "Achim Hensel" (Shift-Entfernen im Explorer) - löschen ohne Kopie im Papierkorb. Dann brauchst Du auch nicht die Kommandozeile unter Win8.1 zu suchen.
Steffen Rose schrieb: > Dann brauchst Du auch nicht die > Kommandozeile unter Win8.1 zu suchen. man lernt nie aus, bei den vielen wegen nach rom.
Angehängte Dateien:
-
Aufnahme1.png
31 KB
Hallo Steffen, weil das nicht funktioniert ! "Die Quelldateinamen sind zu lang für das Dateisystem." Verschieben, Dateinamen kürzen usw. blablabla Mit rd pder rmdir im Command-Fenster geht es leider auch nicht. D:\Programmieren\Arduino\work>rd /S/Q .\libraries D:\Programmieren\Arduino\work>rmdir /S/Q .\libraries "Das System kann den angegebenen Pfad nicht finden". Irgendwie bin ich mal wieder am A*sch
Hans-werner M. schrieb: > D:\Programmieren\Arduino\work>rd /S/Q .\libraries > D:\Programmieren\Arduino\work>rmdir /S/Q .\libraries > > "Das System kann den angegebenen Pfad nicht finden". dann gib doch mal "D:\Programmieren\Arduino\work>rd /S/Q libraries" ein. win mag da ".\" nicht
Auja, das ist fein. rd /S /Q libraries \libraries\libraries\libraries\libraries\libraries\libraries\libraries\l ibraries\libraries\libraries\libraries\libraries\libraries\libraries\lib raries\libraries\libraries\libraries\libraries\libraries - Das Verzeichnis ist nicht leer. Bitte nicht auf die Anzahl der \libraries festnageln.
Nein, nichts hat funktioniert. Das das Verzeichnis nicht leer ist und damit nicht gelöscht werden kann, war ja die Fehlermeldung.
Nicht vorhanden. Ein aktuelles Backup ist vorhanden. Also zurückspielen.
Hans-werner M. schrieb: > rd /S /Q libraries Ist es windows egal, ob Gross oder klein /S /s ? Eventuell gibt es versteckte oder als System gekennzeichnete Dateien attrib -h -s libraries\*.* /s
/s /q gross/klein ist egal. es gibt a nur eine "sicherheit" bei verzeichnisstrukturen. gabs (ich weis nicht ob immer noch) bei linux nicht. unter linux bin ich mal mit rd und einem "." zuviel ins verzeichns ins root gerutscht. es wurde konsequent gemacht! system death! kein bedarf es erneut zu testen... man muss unter win halt wirklich n-mal machen.
Kommt drauf an, was es ist. Ein "reparse point" vgl. Symlink, oder ein Hardlink. Bei Letzterem: "If the filesystem already has a circular reference then running chkdsk with the /f switch is the only way to resolve the issue." https://kb.acronis.com/content/39356 Andernfalls könnte evtl. schon Rename helfen.
:
Bearbeitet durch User
und google findet auch sowas: http://unsicherheitsblog.de/leere-ordner-finden-und-loschen-rekursiv/1150
Wie ist denn das rekursive Verzeichnis entstanden ? Reperaturkonsole öffnen und dann > chkdsk /f /r /x > rd /s /q .\pfad > del /f /s /q .\pfad\*.* Wenn das nix bringt wie schon gesagt LiveCD und weg damit ... chkdsk /f /r /x aber unbedingt vorher auf Reperaturkonsole durchführen, kann je nach Plattengröße seeeehr lange dauern ...
CMD öffnen und mit folgendem Befehl löschen: rd /s /q "\\?\LW:\Pfad" Anstelle von LW und Pfad entsprechend deinen Laufwerksbuchstaben und Pfad angeben.
Ich würde auf alle Fälle erstmal die Fehlerüberprüfung laufen lassen, sonst zerschießt Du Dir noch die Partition D: mit irgendwelchen Experimenten. Als ich im Job neu anfing, waren 1991 nur SUNs am laufen und wenige PCs. Netzwerk war noch das mit den BNC-Kabeln. Und irgendein UNIXer fand es wohl witzig, in jedem Verzeichnis einen Link auf sich selbst zu setzen. WINDOWS/DOS hat sich dann totgesucht bis zum Absturz. Einmal bekam ich eine Fehlermeldung, den Wortlaut weiß ich nicht mehr, aber sinngemäß: "Diese Fehlermeldung dürfte eigentlich nie erscheinen." Vielleicht: "unexpected error message"
:
Bearbeitet durch User
Icke ®. schrieb: > CMD öffnen und mit folgendem Befehl löschen: Wenn das eine Hardlink-Schleife sein sollte, dann dürfte das kaum funktionieren.
Peter Dannegger schrieb: > Und irgendein UNIXer fand es wohl witzig, in jedem Verzeichnis einen > Link auf sich selbst zu setzen. Und hat ihn nicht zufällig "." genannt? ;-)
:
Bearbeitet durch User
A. K. schrieb im Beitrag #4139650:
> Ist in Windows auf lokaler Disk nicht anders, ebenso DOS:
Du hast aber z.B. in "Windows" keinen Link "Windows".
C:\Windows>cd Windows
Das System kann den angegebenen Pfad nicht finden.
Hatte das erst missverstanden. Ist mir aber in Unix noch nie begegnet. Hardlinks auf Directories lassen sich heute auch nicht mehr erzeugen.
:
Bearbeitet durch User
http://superuser.com/questions/620442/how-can-one-delete-recursive-directories-in-windows Use some Robocopy tricks, quote: Create a dummy folder on the drive (D: in this example) where the elongated path lives: md AnyFolderName Copy the dummy folder to the mutant folder using the /MIR (mirror) command line switch: robocopy D:\AnyFolder D:\BackupFolder /MIR Let RoboCopy clean up the fouled folder. This could take a few minutes depending on the size of the folder. Remove the fixed folder and the dummy folder: rd /s D:\BackupFolder rd /s D:\AnyFolder That’s it. You are good to go.
Bitte nicht schlagen dass ich jetzt mit DEM tool komme, aber der TotalCommander wird das mit großer Wahrscheinlichkeit löschen können! ;-)
Holger schrieb: > Bitte nicht schlagen dass ich jetzt mit DEM tool komme, aber der > TotalCommander wird das mit großer Wahrscheinlichkeit löschen können! > ;-) ich glaube nicht dass der TC mit überlangen Dateinamen klar kommt.
Unendliche Pfade in endlicher Zeit abzuarbeiten, das schafft auch der TC nicht, das schafft nur Chuck Norris. ;-)
A. K. schrieb: > Unendliche Pfade in endlicher Zeit abzuarbeiten, das schafft auch der TC > nicht, das schafft nur Chuck Norris. ;-) Endlich eine vernünftige Antwort. Der TO meldet sich nicht mehr -er wird sich doch nicht am Verzeichnisbaum aufgehangen haben? MfG Paul
A. K. schrieb: > Unendliche Pfade in endlicher Zeit abzuarbeiten, das schafft auch der TC > nicht, das schafft nur Chuck Norris. ;-) Der Pfad ist ja auch nicht unendlich, sondern nur endlos. Das Problem ist nur, dass der Explorer anscheinend nicht in der Lage ist, den Unterschied zu erkennen, weswegen er sofort aufgibt. Das heißt aber nicht, dass andere Tools diesbezüglich nicht etwas intelligenter sind (Chkdsk scheint ja mit dem Problem umgehen zu können). Dem TC traue ich diese Fähigkeit aber nicht zu, denn der ist für andere Dinge gemacht. Für ext2-, ext3- und ext4-Filesysteme können mit dem Tool debugfs Directory-Hardlinks (auch zyklische) ganz einfach erzeugt und auch wieder gelöscht werden, ohne dass dafür das gesamte Filesystem gecheckt werden muss. Vielleicht gibt es ja ein vergleichbares Tool auch für NTFS. Ansonsten würde es auch mich interessieren, wie dieser zyklische Hardlink (wenn es überhaupt einer ist) zustanden kam. Auf eine ähnliche Weise kann man ihn vielleicht auch wieder löschen. Paul Baumann schrieb: > Der TO meldet sich nicht mehr -er wird sich doch nicht am > Verzeichnisbaum aufgehangen haben? Der sucht immer noch das Pfadende und dreht sich dabei im wahrsten Sinne des Wortes im Kreis :)
Google findet mit der genannten Fehlermeldung etliche Treffer, u.a. http://www.borncity.com/blog/2009/12/14/pfadlangenlimit-uberschritten-dateisystemobjekte-scheinbar-nicht-mehr-loschbar/ Total Commander soll helfen, ebenso http://www.purgeie.com/delinv/dldelinv.htm (ältere Versionen sind noch keine Shareware)
Ein sehr nettes Tool, was bei mir seit Jahren zur Grundausstattung gehört ist Link-Shell-Extension. Das symolsiert im Explorer Hardlinks/Symlinks und Junctions und behandelt sie auch vernünftig, wenn sie verschoben/gelöscht oder kopiert werden. Dein Problem kann meiner Meinung nach entweder wirklich ein Dateisystemfehler sein, oder eine Junction oder ein Symlink (gibts erst seit der NTFS-Version von Vista oder so).
> Verzeichnis erzeugt worden. libraries\libraries\libraries ..
Wenn es mit Linux erzeugt wurde, sollte man es mit Linux auch wieder
löschen können.
Mit Windows ist das weniger erfolgreich. Das merkt man schon frühzeitig
mit dir /s wenn Windows in diesem Ordner meckert, daß es nicht alles von
der Namenslänge zeigen kann. Das tückische an der Sache ist, daß auch
ein Backup nicht komplett sein könnte.
schon probiert falls es ein Window- Rechner ist? rechte Maustaste auf Laufwerk, tools-> Fehlerüberprüfung -> jetzt prüfen
:
Bearbeitet durch User
Bei verstuemmelten Verzeichnissen habe ich mit meinem liebgewordenen Total-Commander auch schon einmal Schiffbruch erlitten. Alles kann der ebend auch nicht. Ein: "rm verzeichnis /s" im CDM-Fenster fuehrte auch nicht zur erfolgreichen Ausfuehrung. Ein "rmdir verzeichnis /s" brachte aber dann den gewuenschten Erfolg. Den Schalter "/q" habe ich nicht benutzt, da muss ich glatt mal lesen gehen. Gruss Asko.
A. K. schrieb: > Ist mir aber in Unix noch nie begegnet. > Hardlinks auf Directories lassen sich heute auch nicht mehr erzeugen. Linux ist nicht die Welt! http://docs.oracle.com/cd/E23823_01/html/816-5166/unlink-1m.html Man muss aber schon root sein um das machen zu dürfen.
Konrad S. schrieb: > A. K. schrieb: >> Ist mir aber in Unix noch nie begegnet. >> Hardlinks auf Directories lassen sich heute auch nicht mehr erzeugen. > > Linux ist nicht die Welt! > > http://docs.oracle.com/cd/E23823_01/html/816-5166/unlink-1m.html > Man muss aber schon root sein um das machen zu dürfen. Du beziehst dich auf Solaris 10 8/11 von 2011. In der aktuellen Version (11.2 von 2014) scheint das nicht mehr zu gehen: Aus link(1M):
1 | Note that the ZFS file system does not support links between directories. |
Demnach geht es zumindest für ZFS nicht. Blättert man im Manual aber etwas weiter, sieht es so aus, dass Hardlinks auf Verzeichnisse generell unterbunden werden: Aus link(1M):
1 | link and unlink directly invoke the link(2) and unlink(2) system calls |
Aus link(2):
1 | No process can make a link to a directory, file named by path1 must not |
2 | be a directory. |
Hardlinks auf Verzeichnisse sind also inzwischen wohl auch in Solaris abgeschafft.
Yalu X. schrieb: > Hardlinks auf Verzeichnisse sind also inzwischen wohl auch in Solaris > abgeschafft. Ich werde sie nicht vermissen. ;-) Opa erzählt vom Krieg: Den einzigen Fall hatte ich vor zwanzig Jahren bei SunOS4. Da war unlink sehr hilfreich.
Konrad S. schrieb: > Yalu X. schrieb: >> Hardlinks auf Verzeichnisse sind also inzwischen wohl auch in Solaris >> abgeschafft. ich find sie wahnsinnig praktisch und bin froh, dass es sowas unter NTFS gibt.
Vlad Tepesch schrieb: > ich find sie wahnsinnig praktisch und bin froh, dass es sowas unter NTFS > gibt. Hardlinks auf Directories???? Na Prost! Softlinks bzw. Reparse Points sind eine andere Baustelle. Hardlinks auf Dirs sind jedoch ausser "." und ".." eher Problem als Hilfe.
:
Bearbeitet durch User
Vlad Tepesch schrieb: >>> Hardlinks auf Verzeichnisse sind also inzwischen wohl auch in Solaris >>> abgeschafft. > > ich find sie wahnsinnig praktisch und bin froh, dass es sowas unter NTFS > gibt. Laut dieser Doku sind auch bei NTFS keine Hardlinks auf Verzeichnisse erlaubt: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860%28v=vs.85%29.aspx
1 | This function is only supported on the NTFS file system, and only for |
2 | files, not directories. |
Für Verzeichnisse gibt es Junctions, aber die scheinen eher eine Art symbolische Links zu sein. Symbolische Links sind ungefährlich und dürfen auch in Unix/Linux auf Verzeichnisse zeigen und rekursiv sein.
Apropos "..": Wohin zeigt das eigentlich, wenn es aufgrund Hardlinks keinen eindeutigen Rückweg gibt? Historisches Würfelspiel?
A. K. schrieb: > Apropos "..": Wohin zeigt das eigentlich, wenn es aufgrund Hardlinks > keinen eindeutigen Rückweg gibt? Historisches Würfelspiel? Der ".." wird beim Erzeugen des Verzeichnisses angelegt. Insofern ist das schon eindeutig.
Konrad S. schrieb: > Der ".." wird beim Erzeugen des Verzeichnisses angelegt. Insofern ist > das schon eindeutig. Wobei ein konsistentes System draus wird, wenn man dann mit unlink() jene überzähligen Directory-Links wieder loswerden kann, die man mit link() erzeugt hat. Dann kriegt man Schleifen auch wieder weg. Der API Dokumentation zufolge könnte das mal so gewesen sein.
Hat schon seine Berechtigung, dass der Normal-User da nicht hinlangen darf. Directory-Hardlinks sind ja schon ohne Rekursion nicht unproblematisch.
A. K. schrieb: > Hardlinks auf Directories???? Na Prost! > > Softlinks bzw. Reparse Points sind eine andere Baustelle. Hardlinks auf > Dirs sind jedoch ausser "." und ".." eher Problem als Hilfe. Yalu X. schrieb: > Laut dieser Doku sind auch bei NTFS keine Hardlinks auf Verzeichnisse > erlaubt: Yalu X. schrieb: > Für Verzeichnisse gibt es Junctions Puh - keine Ahnung, wo die Unterschiede zwischen Hardlinks und Reparsepoints und Symlinks liegen. unter NTFS gibts - Hardlinks - nur für Dateien - Junktions - nur für Verzeichnisse - und (seit Vista) Symlinks für beides - Pif und Lnk - dateien - entspricht wohl Softlinks Keine Ahnung wo die unterschiede zwischen den ersten Drei liegen. Scheinen ansich das gleiche zu machen :-)
In Win kann man es noch im abgesicherten Modus versuchen. Unloker ist auch manchmal nützlich bei verquerten Dateien. http://www.chip.de/downloads/Unlocker_18414122.html
PS: Ob unlocker mit Win8/8.1 funzt, müsste man ausprobieren. Ich arbeite noch mit Win 7, und kann das daher nicht mir Sicherheit sagen. Aber,....probieren geht über studieren ;-)
Vlad Tepesch schrieb: > Keine Ahnung wo die unterschiede zwischen den ersten Drei liegen. > Scheinen ansich das gleiche zu machen :-) Unix-Filesysteme unterscheiden traditionell zwischen Files und Directory-Einträgen. Ein File (Inode) ist durch eine eindeutige Nummer gekennzeichnet. Directories bestehen aus einer Liste von Filenamen und der dazugehörigen Inode-Nummer. Daher können mehrere Directory-Einträge auf das gleiche File verweisen (reference counted). Das sind Hardlinks. Gibts auch in NTFS, war aufgrund des in NT eingebauten POSIX Subsystems nötig. Bei mehrfach verlinkten Files sind alle Links gleichwertig, es gibt also kein Original. Wie benennt man in Unix Dir-Einträge um: Hardlink mit neuem Namen auf File setzen und alten Namen löschen. Im ursprünglichen Unix-API existierte daher keine Rename-Operation. Und die Löschoperation hiess korrekterweise unlink(). Nebeneffekt von Unix-Hardlinks: Es gibt Files, auf die kein Dir-Eintrag mehr verweist, noch so lange, bis der letzte Prozess sie geschlossen hat. Man kann also Files löschen, die offen sind, weil man damit zunächst nur den Dir-Eintrag löscht. Erst wenn sowohl die erwähnte Dir-Refcount als auch die Handle-Refcount auf 0 sind wird die Inode gelöscht. Symbolic Links aka Symlinks hingegen kamen in Unix erst später auf und sind spezielle Files. Deren Inhalt ist der Pfad, an dem es weiter geht. Verschwindet das Ziel dieses Verweises, dann hängt der Symlink in der Luft. Im Unterschied zu Hardlinks sind die auch über die Grenzen von Filesystemen machbar. Hat auch bei Backups gewisse Vorteile, denn bei Hardlinks ist es nicht ganz so einfach, eine Trennung mehrfach verlinkter Inodes zu vermeiden.
:
Bearbeitet durch User
PS: Vorteil von Hardlinks: Man kann versionierte Backups herstellen, bei denen auf der Backup-Disk der Stand jedes einzelnen Backups vollständig als völlig unabhängiger Dateibaum vorhanden ist. Ohne dabei aber unveränderte Files repliziert vorzuhalten, weil die einfach auf den Vorgänger verlinkt werden. Man kann jeden Baum beliebig ohne Nebeneffekte löschen. Mit Symlinks ist das nicht so einfach möglich. Wird beispielsweise von rsync so durchgeführt, und von ein paar Windows-Programmen wie Hardlinkbackup.
:
Bearbeitet durch User
Ich hatte das Problem auch. Das Verzeichnis ist nicht rekursiv, sondern einfach nur sehr tief. Die Lösung besteht darin das libraries Verzeichnis in ein temporäres Verzeichnis zu verschieben z.B.: TmpDelete. Das libraries Verzeichnis umzubenennen (z.B.: '1'). Dann so weit wie's geht (10-20 mal) in das Verzeichnis zu wechseln. Dort das nächste .libraries wieder ins temporäres Verzeichnis zu verschieben und '1' zu löschen. Das macht man dann so 20-30 Mal und dann ist es leer. Hier mein Script. Ich hab's im Laufwerk G gemacht: cd G:\TmpDelete\ ren libraries 1 cd G:\TmpDelete\1\libraries\libraries\libraries\libraries\libraries\librari es\libraries\libraries\libraries\libraries\libraries\libraries\libraries \libraries\libraries\libraries\libraries\libraries\libraries\libraries move '.\libraries\' G:\TmpDelete\ cd G:\TmpDelete\ rmdir '.\1' -Recurse
Ich habe das Problem aktuell auch (unter Windows 10). Meine Struktur ist: ...\###DigiKam\_GoogleFotos\Eigene Bilder Beim Versuch, das Dir "Eigene Bilder" zu löschen oder umzunennen oder sogar auch nur mit dem cd Befehl ins Directory zu wechseln, dann kommt die Meldung: Das System kann den anegebenen Pfad nicht finden. Hat noch jemand eine Idee? Unlocker kann das Ganze auch nicht lösen.
Wolfisch schrieb: > Hat noch jemand eine Idee? Unlocker kann das Ganze auch nicht lösen. Leerzeichen! "Eigene Bilder" schreiben.
Sorry, was meinen Sie mit Leerzeichen! "Eigene Bilder" schreiben. ??? F:\_MyFiles\z\ccc\Hase\_GoogleFotos\Hasen\###DigiKam\_GoogleFotos\x1\### DigiKam\_GoogleFotos\x2\###DigiKam\_GoogleFotos\x3\###DigiKam\_GoogleFot os\x4\###DigiKam\_GoogleFotos\x5\###DigiKam\_GoogleFotos\x6\###DigiKam\_ GoogleFotos\xxx\###DigiKam\_GoogleFotos>cd "Eigene Bilder" Das System kann den angegebenen Pfad nicht finden.
F:\_MyFiles\z\ccc\Hase\_GoogleFotos\Hasen\###DigiKam\_GoogleFotos\x1\### DigiKam\_GoogleFotos\x2\###DigiKam\_GoogleFotos\x3\###DigiKam\_GoogleFot os\x4\###DigiKam\_GoogleFotos\x5\###DigiKam\_GoogleFotos\x6\###DigiKam\_ GoogleFotos\xxx\###DigiKam\_GoogleFotos ist 255Bytes lang. Scheint wohl knapp zu lang zu sein, um in einem Rutsch angesprochen zu werden. Vielleicht klappt ja noch "cd E*" ;-)
:
Bearbeitet durch User
Ich würde es erst mal mit so einem NC-Commander Clone versuchen. Unter XP hatte es mir mal geholfen. Ob es unter W10 geht???
>Ich würde es erst mal mit so einem NC-Commander Clone versuchen. >Unter XP hatte es mir mal geholfen. >Ob es unter W10 geht??? Eigentlich kommt es bei Win nur auf die Arbeitsweise der Tools an. Wenn die intern ständig mit absoluten Pfaden operieren, sind die schnell bei 256Bytes an der Grenze (bzw. irgendwo um 260B mit LW), und Win finden den Pfad (vermutlich, weil intern abgeschnitten) dann nicht mehr. Wenn dagegen mit rel. Pfaden gearbeitet wird, kann man eigentlich fast beliebig weit in die Pfade eintauchen (soweit ich weis, ist das nicht wirklich fest begrenzt). Dies ist aber wohl alles noch ein Relikt aus DOS-Zeiten, und wird durch interne Parameter-Limits der Win-API verursacht. NTFS selbst kann weit längere Pfadstrings verdauen, und sollte via UNC-Namen auch komplett ansprechbar sein
Wie entstehen denn solche sinnlosen Verzeichnisnamen? Man kann in der CMD-Box mit subst einem Verzeichnis einen Laufwerksbuchstaben zuweisen und damit darauf zugreifen.
Jens G. schrieb: > Wenn die intern ständig mit absoluten Pfaden operieren, sind die schnell > bei 256Bytes an der Grenze (bzw. irgendwo um 260B mit LW), und Win > finden den Pfad (vermutlich, weil intern abgeschnitten) dann nicht mehr. Dann sind die Programmierer einfach nur unfähig - in der Dokumentation der Win32-API steht seit über zwei Jahrzehnten, wie man die Pfadlänge auf ca. 32k Zeichen erhöhen kann. Das Problem ist also lösbar.
michael_ schrieb: > Ich würde es erst mal mit so einem NC-Commander Clone versuchen. Danke für den Tipp! Habe es mit FreeCommander geschafft, den Pfad zu löschen. Gibt mir echt zu denken, dass es im Jahr 2017 nicht möglich ist, das mit Windows Bordmitteln machen zu können. Hatte mich gestern noch an den Microsoft Support gewandt - das hätte ich mir auch sparen können. @Peter Dannegger (peda): Der Pfad wurde von der Software DigiKam erstellt - warum die rekursive Pfade anlegen, ist mir schleierhaft - habe diese auch gleich wieder deinstalliert.
> Dann sind die Programmierer einfach nur unfähig - in der Dokumentation > der Win32-API steht seit über zwei Jahrzehnten, wie man die Pfadlänge > auf ca. 32k Zeichen erhöhen kann. Das Problem ist also lösbar. Dann erkläre das mal den Leuten, die den Windows-Explorer geschrieben haben... Dort ist auch bei ca. 256 Zeichen Pfadlänge Schluss (zumindest unter XP und W7)
Rufus Τ. F. schrieb: > Dann sind die Programmierer einfach nur unfähig - in der Dokumentation > der Win32-API steht seit über zwei Jahrzehnten, wie man die Pfadlänge > auf ca. 32k Zeichen erhöhen kann. Das Problem ist also lösbar. Ja, bloss die blinden Wichser bei Winzigweich selber haben das offensichlich bis heute nicht begriffen. Jedenfalls die von der Surface-Division... Im Kernel selber ist das absolut kein Problem. Aber mal ganz davon ab: auch du hast es nicht wirklich begriffen. Das, was du meinst, zielt nur darauf ab, längere absolute Pfade handeln zu können. Das ist aber auch garnicht nötig, wenn man sich mit relativen Pfaden begnügt. Das klappt bis zu (theoretisch beliebiger) Tiefe, praktisch natürlich nicht, da man sich ja irgendwo den Pfad merken muss, stellt also das Fassungsvermögen des virtuellen Adressraums bzw. des darunterliegenden Swapfiles das Limit dar. However: gegen eine echte Rekursion ist eh' kein Kraut gewachsen, da wirken alle stupiden Limitierungen eher positiv: der ganze Scheiß merkt dadurch nur schneller, dass er damit nicht klarkommt. Richtig guter Code, würde einfach nur sehr viel länger brauchen, um am Ende zum exakt gleichen Schluß zu kommen...
c-hater schrieb: > Aber mal ganz davon ab: auch du hast es nicht wirklich begriffen. Ach, danke. Dem Threadstarter ging es wohl in erster Linie darum, einen vergurkten Verzeichnsibaum loszuwerden, nicht durch "elegante" rekursive Programmierung so etwas anzulegen. Das hat ja für ihn schon irgendein Deppenprogramm hinbekommen. Mir zumindest ist noch kein Fall begegnet, wo tatsächlich vollständige Rekursion in Verzeichnisbäumen beliebiger Tiefe irgendeinen Sinn abseits der Befriedigung akademischer Hirngespinste darstellt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.