sekaczek

Hallo Zahni, und wie ich auch schon oben geschrieben habe: das Behalten der Position (also nur eine Veränderung der Verweise) ist keine logische Erklärung. Warum dann werden Archivbits bei Umbenennen und/oder Verschieben von Dateien gesetzt. Die Dateien ändern bei dieser Aktion auch ihre Position nicht und es werden auch nur Verweise angepasst. Trotzdem wird das Bit gesetzt. Außerdem war das nicht meine Frage - siehe oben Gruß Sekaczek

Hallo Günther na ja eine Erklärung wurde ich das nicht unbedingt nennen. Es wurde eher gesagt, dass die Bits nicht gesetzt werden, weil sie nicht gesetzt werden - siehe das andere Forum. Außerdem, habe ich auch keine Erklärung gebraucht und um keine Erklärung gebeten, sondern nur gefragt, ob man das Verhalten mit z. B. einem, mir noch unbekannten, Registry-Key ändern kann. Das Verhalten an sich ist mir schon länger bekannt, nur hat mich bis jetzt nicht gestört. Bis zu diesem Kunden eben. Ich fand es aber nie, dass das bezogen auf Dateien einerseits und auf Verzeichnisse andererseits unterschiedliche Verhalten normal ist. Entweder in beiden Fällen Bits setzen oder in beiden nicht - dies wäre normal. Warum es so nicht gemacht wurde, kann ich nur vermuten - wahrscheinlich hat man in der Vergangenheit Performance-Probleme bei Umbenennen von Verzeichnissen mit vielen Dateien vermeiden wollen. Gruß Sekaczek

Hallo, soll ich das so verstehen, dass niemand sonst eine Antwort auf meine Frage hat? :( Gruß Sekaczek

Danke für Deine Antwort. Es ist mir schon klar, dass das Verzeichnis nirgendwo physikalisch verschoben sondern nur "umgehängt" wird (solange alles innerhalb einer Partition passiert). Wichtig sind aber am Ende die Ergebnisse/Auswirkungen für den User und nicht das, wie es technisch realisiert ist. Außerdem, ist das Verhalten beim Umbenennen/Verschieben von Verzeichnissen und Dateien inkonsistent: beim Umbenennen/Verschieben von Dateien innerhalb einer Partition, wird auch nichts tatsächlich verschoben, sondern nur "umgehängt". Trotzdem werden in diesem Fall die Archivbits gesetzt. Bei Verzeichnissen aber nicht, weder für die Dateien, noch für das Verzeichnis selbst. Es geht um einen kleineren Kunden, bei dem ich das Netzwerk supporte. Er verwendet ein einfaches Backup-Programm und möchte auf kein anderes (teures) umsteigen. Ich habe ihn Robocopy vorschlagen wollen, aber es würde auch nichts bringen. Robocopy verhält sich auch nicht anders, wenn man Archivbits verwendet. Außerdem möchte er ein Tool mit GUI haben. Und auf Zeitstempel-Synchronisierung möchte er sich nicht verlassen, weil seine Mitarbeiter oft Dateien auf mit FAT32 formatierten Datenträger hin und her transportieren und bearbeiten, wodurch man wieder das Problem mit der Zeitumstellung hat. Insgesamt ein "schwieriger Fall" :rolleyes: ;) Wenn man sich auf die Mitarbeiter verlassen könnte, würde man als Notlösung in der Registry ein neues Shell-Eintrag mit "attrib +A . . ." erstellen, aber da gibt es keine Garantie, dass es immer verwendet wird. Gruß Sekaczek

Hallo, bei differenziellen und inkrementellen Backups gibt es das folgende Problem: Wenn ein Verzeichnis umbenannt und/oder verschoben wird, werden von Windows die Archivbits der darin enthaltenen Dateien nicht gesetzt. Die Dateien in solchem Verzeichnis werden deswegen bei einem darauf folgenden differenziellen oder inkrementellen Backup nicht gesichert. Dadurch kann es zu schwer nachvollziehbaren (ja sogar zur kaum reparablen) Fehlern nach einer Wiederherstellung kommen. Noch schlimmere Folgen (Daten-Verlust) wird es haben, wenn jemand anhand der Archivbits Verzeichnis-Synchronisierung durchführt, die so konfiguriert ist, dass die im Quell-Verzeichnis nicht mehr vorhandenen Daten auch im Ziel-Verzeichnis gelöscht werden. FRAGE: Weiß jemand von Euch, ob (wie) man das Verhalten von Windows ändern kann. ================================================================ Gruß Sekaczek PS Getestet auf Windows XP, Server 2003 und 2008 R2.

. . . eine weitere Beobachtung: Es funktioniert nicht korrekt nur dann, wenn man direkt an der Konsole angemeldet ist. In einer RDP-Sitzung funktioniert es überraschenderweise korrekt. Gruß Sekaczek

Hallo, zugegeben, es ist kein wichtiges Problem, aber es nervt mich trotzdem, weil es nicht wie erwartet funktioniert und ich weiß nicht warum. Ich verwende manchmal "psexec.exe -L" um einige Anwendungen bequem ohne Administrator-Rechte zu starten, zum Beispiel Internet Explorer oder Firefox. Manchmal benutze ich auch das freie Übersetzungstool "Lingoes" portable. Leider funktioniert es nicht in jeder Konstellation korrekt. Ohne psexec öffnet sich ein kleines Pop-Up-Fenster von Lingoes mit Übersetzung, wenn ein Text mit Doppelklick oder durch Ziehen der Maus markiert wird. Das Fenster wird dann automatisch durch eine schnellere/längere Bewegung des Maus-Zeigers wieder geschlossen. Mit psexec funktionieren diese beiden Funktionen (Übersetzungsfenster öffnen und schließen) nicht, wenn sich der Mauszeiger im Bereich des Fensters der mit "psexec.exe -L" gestarteten Anwendung befindet. Es funktioniert so (nicht) auf einem standalone Server 2003 Enterprise SP2 und zwar nur dann, wenn sich das Benutzerkonto in der Administratoren-Gruppe befindet. Bei einem Konto ohne Administrator-Rechte arbeitet die mit "psexec.exe -L" gestartete Anwendung zwar korrekt mit Lingoes zusammen, es ist aber sinnlos "psexec.exe -L" ohne Administrator-Rechte zu verwenden. Als ich das früher mal auf einem alten System (XP Professional SP1) eingesetzt habe, gab es überhaupt keine Probleme - es funktionierte auch mit einem Administrator-Konto korrekt. Irgendwelche Ideen? Gruß, Sekaczek PS. Es ist mir noch unbekannt, ob es außerdem noch andere/weitere Probleme gibt, wenn man Anwendungen mit "psexec -L" in diese Konstellation startet. Wie gesagt, es geht hier nicht ums Lösen eines wichtigen Problems, sondern nur um Verständnis, warum es nicht tut.