Hallo, ich (oder ein Programm) hat irgendwie eine Rekursion im Filesystem zustande gebracht. Im Screenshoot - ist der blaue Pfeil am Folder sowas wie ein symbolischer Link? Wenn ja, wie komm ich auf das Ziel des Linkes? Gruss Heinz
Angehängte Dateien:
-
Clipboard01.png
11 KB
heinz schrieb: > Wenn ja, wie komm ich auf das Ziel des Linkes? rechter Mausklick, Eigenschaften? Das muss keine Rekursion sein, der Link kann auch auf eine anderes Verzeichnis irgendwo im Dateisystem zeigen. Im übrigen ist eine Dateiangabe wie \test\test\test problemlos zulässig. Also kommst du mit Application data\Application data dahin wo du hinwillst, egal wo das ist. Georg
Da gibts bei mir nur Allgemein Sicherheit Vorgängerversion / Anpassen Hab den Pfad jetzt mal auf eine FAT32 kopiert und überleg mir ob ich ihn zurück kopier?
@Georg Das ist schon rekursiv. Wenn ich in dem Pfad suche läuft sich der Explorer tot.
heinz schrieb: > Wenn ich in dem Pfad suche läuft sich der > Explorer tot. Wenn du rekursiv suchst, findet der in jedem Verzeichnis A.. data, das er aufmacht wieder ein solches Verzeichnis. Aber aufmachen und anschauen sollte normal funktionieren. Georg
>Aber aufmachen und anschauen sollte normal funktionieren.
Das geht natürlich. Ich überleg halt einfach den Ordner(?) App Data im
Ordner App Data zu löschen.
Was mich dabei stört ist dass der 1. Ordner auch schon den blauen Pfeil
hat
und ich nicht weiss was der bedeutet
heinz schrieb: > Das geht natürlich. Ich überleg halt einfach den Ordner(?) App Data im > Ordner App Data zu löschen. Kannst ihn ja erst mal umbenennen...
Hab ich schon ;) dann haben sie alle einen neuen Namen. Wenn ich denn inneren Pfad lösche ist der äussere mit weg.
https://wordlinks.wordpress.com/2010/10/30/solved-appdatalocalapplicaton-dataapplication-data-repeating-recursion/ Wenn ich das richtig sehe haben die den "Zugriff für alle verweigert" auf den oberen Ordner und alle Unterordner und dann nur den untergeordneten link wieder freigegeben und gelöscht. Ohne Garantie ;-)
Danke schön, jetzt komme ich der Sache näher http://www.sevenforums.com/general-discussion/115149-stop-application-data-folder-replicating.html
Kurze Rückmeldung Wie ich das verstehe ist das irgend ein Murks von MS. Der "Ordner" ist ein Junction auf ProgramData und soll lt. MS irgend einen Sinn haben wenn Programme diesen scannen. Lösung ist jedem Benutzer die Zugriffsrechte entziehen.
heinz schrieb: > und soll lt. MS irgend einen Sinn haben Dieser Sinn erschließt sich mir gerade nicht, zumal es in den VBorgängerversionen von "Fester" auch ohne dieses feature ging. Ist wohl nur eine weitere Verschlimmbesserung von den Yankies, die der Benutzbarkeit von Windows weiter abträglich ist. Möglicherweise geht Microsoft von ihrem eigenen Volk aus. Das aber ist ein anderes Thema...
Zitat This recursive file structure is indeed caused by the implementation of junction points in the NTFS file structure by Microsoft. Essentially, some "folders" are not actual folders at all, but junction or reparse points, which essentially reroute a directory name to another directory. This is much like mapping a drive letter to a directory or another drive, and the Windows system is designed to handle this NTFS structure situation behind the scenes. In Vista and 7, Microsoft decided to standardize some of the typical Windows settings for users, documents, etc., which had varied over time. To maintain backward compatibility, the old standards were also retained BUT WITH JUNCTIONS REPARSING THEM TO REDIRECT INQUIRIES INTO THE NEW ACTUAL DIRECTORIES. Most programs work right through these junctions without even noticing. For example, C:\Documents and Settings points to C:\Users. Even though the former directory does not actually exist, it APPEARS to have the files and directories under the latter, and a change in the contents of either directory will be reflected in the other, since they are in fact, a single directory. The difficulty comes from certain Reparse Points which essentially redirect to a parent directory. This causes a recursive cascade for unwary programs or users who are unaware of the proper handling of the junctions (even though the junctions are designed to be transparent to software looking for either directory). The usual "subdirectory explosion" situation comes from the fact that the \Documents and Settings\$USER$\Application Data folder (consistent with XP convention) is a junction point in Vista to \Users\$USER$\AppData\Roaming, which in turn can contain the Application Data junction as a subdirectory... Under normal Windows permissions, the junctions and their directories are inaccessible and hidden. If permissions are changed or programs working outside Windows are not prepared to encounter these junctions, duplication and recursion is destined to occur. For those using powerful low-level command interfaces such as Repair Console, it is best to check the capabilities and switches on the commands by using the /? help switch (for example, Robocopy /?, xcopy /?, rd /?, etc.). If you are not sure what you are doing, be sure to backup ahead of time with a reliable Windows program, with proper use of Restore Points.
Das klingt alles mal wieder danach, daß Microsoft versucht hat, ein Feature von anderen Systemen zu kopieren (symlinks), aber es nicht richtig verstanden hat und deshalb schlecht implementiert und falsch benutzt.
Rolf Magnus schrieb: > Das klingt alles mal wieder danach, daß Microsoft versucht hat, ein > Feature von anderen Systemen zu kopieren (symlinks), aber es nicht > richtig verstanden hat und deshalb schlecht implementiert und falsch > benutzt. Das ist eher eine Sache der Anwendungen als des Systems. Wenn ein System Symlinks auf Verzeichnisse unterstützt, dann müssen die Anwendungen mit möglichen Schleifen zurecht kommen. Nur sind ältere Windows-Anwendungen das nicht gewohnt. Bei Unix/Linux-Symlinks kriegst du auch Schleifen hin. Und auch da kommen nur manche Programme mit Schleifen zureicht. So folgen Programme, die Filesysteme durchwandern, Symlinks sicherheitshalber lieber nicht, wenn sie schlau genug sind. Wenn man sie freilich dazu überredet, Symlinks zu folgen, dann kriegst du da z.T. den gleichen Zirkus. So erkennt zwar "find" eine Schleife, "tar" jedoch nicht. > find -L . . find: Dateisystemschleife erkannt; "./a" ist ein Teil der Schleife ".". > tar chvf /dev/null . ./ ./a/ ./a/a/ ./a/a/a/ ./a/a/a/a/ ./a/a/a/a/a/ ./a/a/a/a/a/a/ ./a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/ ./a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/ ... Speicherzugriffsfehler
:
Bearbeitet durch User
A. K. schrieb: > Rolf Magnus schrieb: >> Das klingt alles mal wieder danach, daß Microsoft versucht hat, ein >> Feature von anderen Systemen zu kopieren (symlinks), aber es nicht >> richtig verstanden hat und deshalb schlecht implementiert und falsch >> benutzt. > > Das ist eher eine Sache der Anwendungen als des Systems. Wenn das System rekursive Verzeichnisschleifen zum Normalfall erklärt, ist das schon Sache des Systems. Ich sehe sie als Fehler an, und wenn ein Programm damit klarkommt, betreibt es eben in der Regel Fehlerhandling. > Wenn ein System Symlinks auf Verzeichnisse unterstützt, dann müssen die > Anwendungen mit möglichen Schleifen zurecht kommen. Nur sind ältere > Windows-Anwendungen das nicht gewohnt. > > Bei Unix/Linux-Symlinks kriegst du auch Schleifen hin. Natürlich kriegt man das da auch hin. Es ist aber nicht Teil einer normalen Systeminstallation, sondern in der Regel ein Versehen. Das war es auch, was ich oben mit "falsch benutzt" meine. > tar chvf /dev/null . Damit sagst du aber dem tar explizit, daß es Symlinks nicht einfach als solche mit archivieren, sondern ihnen folgen soll. Natürlich wäre es trotzdem schöner, wenn es eine Erkennung rekursiver Schleifen hätte, die dann mit Fehlermeldung abbricht.
:
Bearbeitet durch User
Rolf Magnus schrieb: > und deshalb schlecht implementiert und falsch benutzt. Nope. Die Links sind ein Zugeständnis an ignorante Programmiererschlampen, die hartcoderte Pfade nutzen, statt wie vorgesehen die Variable %APPDATA%. Die gibt es nicht erst seit gestern, sondern schon seit Anfang dieses Jahrtausends. Das Problem ist ähnlich dem mit "ProgramData" und die Schuld liegt eben NICHT bei MS, sondern bei den 3rd-Party Programmierern. Peter Xuang schrieb: > Dieser Sinn erschließt sich mir gerade nicht, zumal es in den > VBorgängerversionen von "Fester" auch ohne dieses feature ging. > Ist wohl nur eine weitere Verschlimmbesserung von den Yankies, die der > Benutzbarkeit von Windows weiter abträglich ist. Nur weil DU den Sinn nicht begreifst, heißt das nicht zwangsläufig, daß es keinen gibt. Ohne die Maßnahme würde so manche Schlampensoftware nicht mehr laufen und das gäbe viel mehr Geschrei.
Peter Xuang schrieb: > Dieser Sinn erschließt sich mir gerade nicht, zumal es in den > VBorgängerversionen von "Fester" auch ohne dieses feature ging. Der Fehler fing mit Idee an, Systempfade sprachabhängig zu gestalten. Von da an war die Kacke am dampfen. Jede weitere Aktion wurde unter der Vorgabe gestaltet, bestehende Kackprogramme überleben zu lassen. In NT4 installierten sich manche Programme direkt nach "C:\Program Files", egal welche Sprache das System hatte. Im deutschen Windows hatte man dann beides nebeneinander, das richtige "C:\Programme" und das falsche "C:\Program Files". Das konnte schon in XP einige Verwirrung auslösen, da dessen Explorer die Pfade anders anzeigt, als sie auf Disk heissen, um den Spracheffekt anders anzugehen. Besonders wenn im Zugriff über Netz unterschiedliche Sprachversionen verwendet werden (DE-Client, EN-Server). Zudem schreiben viele Programme ihre Daten direkt ins Programmverzeichnis rein. Sysadmins ist das ein Horror, weil man so keine vernünftige Rechtestruktur gebacken bekommt, auch kein Roaming. Also hat MS mit Win7/Vista den Hack mit "ProgramData" eingeführt und die Umbenennung im Explorer wurde zu Symlinks auf Disk. Schöner ist es dadurch mit der Zeit wirklich nicht geworden. Aber MS kann es sich nicht leisten, alte Fehler inkompatibel zu korrigieren und muss mit solchen Hacks leben.
:
Bearbeitet durch User
Also zu aller erst war es mal mein Fehler die Zugriffrechte für den Ordner zu ändern. Was ich nicht verstehe Application Data ist eine Junction auf ProgramData Um nicht rekursiv zu werden entziehe ich Allen die Zugriffsrechte auf Application Data. Dann könnte ich Application Data auch löschen? Wieso sehe ich im Explorer (ich nutze Explorer++) nicht auf was die Junction zeigt?
A. K. schrieb: > Der Fehler fing mit Idee an, Systempfade sprachabhängig zu gestalten. > Von da an war die Kacke am dampfen. Jede weitere Aktion wurde unter der > Vorgabe gestaltet, bestehende Kackprogramme überleben zu lassen. Na, das sind sie seit "Vista" nicht mehr. Die Systempfade haben jetzt nur noch englische Namen; sie werden im Explorer aber in einer lokalisierten Fassung angezeigt. Gleichermaßen erfolgt eine automatische Rückübersetzung, wenn ein Programm versucht, einen lokalisierten Pfad zu nutzen. Dieses Verhalten ist sinnvoll. Das machen andere übrigens auch so; OS X beispielsweise lokalisiert seine Systempfade auch in der Anzeige.
Rufus Τ. Firefly schrieb: > Na, das sind sie seit "Vista" nicht mehr. Die Systempfade haben jetzt > nur noch englische Namen; sie werden im Explorer aber in einer > lokalisierten Fassung angezeigt. Gleichermaßen erfolgt eine automatische > Rückübersetzung, wenn ein Programm versucht, einen lokalisierten Pfad zu > nutzen. > > Dieses Verhalten ist sinnvoll. Darüber läßt sich streiten. Ich finde das nicht ideal, wenn der Filebrowser die Namen heimlich austauscht. Es führt zu Verwirrung. > Das machen andere übrigens auch so; OS X beispielsweise lokalisiert > seine Systempfade auch in der Anzeige. Das macht es nicht besser.
Wer die Wahrheit anzeigen will, sollte FreeCommander nutzen ;-) http://freecommander.com/de/ubersicht/
Rolf Magnus schrieb: > Ich finde das nicht ideal, wenn der Filebrowser die Namen heimlich > austauscht. Nun, es ist der dringend nötige Schritt weg von lokalisierten Pfaden. Die waren eine komplett kaputte Designentscheidung. Und da nicht alle Anwender von Computern anglophon sind, werden sie sicherlich nicht entzückt sein, wenn ihnen Windows plötzlich englischsprachige Pfade vorschreibt. Insofern ist eine virtuelle Lokalisierung schon sinnvoll. Der Explorer verbirgt übrigens die englischsprachigen Pfade nicht komplett, dieses DOS-Revival-Tool braucht man nicht. Klickt man in die Adressleiste, wird aus dem dort dargestellten lokalisierten Pfad der englischsprachige tatsächliche Pfad.
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.