Windows: Wie ein rekursives Verzeichnis löschen ?

CTRL-DELETE im Explorer?
DEL auf der Kommandozeile?

OS?

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 ???

cmd ?

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.

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

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.

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.

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"

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? ;-)

A. K. schrieb:
> Und hat ihn nicht zufällig "." genannt? ;-)

cd user
ls -la
.
..
user
usw.

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.

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.

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 :)

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).

schon probiert falls es ein Window- Rechner ist?
rechte Maustaste auf Laufwerk, tools-> Fehlerüberprüfung -> jetzt prüfen

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.

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 :-)

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.

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.

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*" ;-)

>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.

> 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)

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.