[Rika]

@Talla: Jupp, das ist komisch, denn mit einem Debugger kann man trivial das Gegenteil feststellen. Außer FSCTL_GET_VOLUME_BITMAP und FSCTL_GET_RETRIEVAL_POINTERS sieht man dort keinen FSCTL, insbesondere nicht FSCTL_MOVE_FILE, weil die das selber machen - wohl in der Hoffnung, daß zwischenzeitlich der Cluster nicht neu belegt sein könnte.

[Stefan_der_held]

Zitat (Rika: 05.09.2006, 21:22)

Oder du hast ihn nur nicht bemerkt. Probe auf's Exempel: Lass mal eine große Datei defragmentieren und schalte mittendrin den Rechner hart aus.

Ja ne Rika: Wenn du eine Datei (jetzt mal normal ohne irgentwelche Defragmentierer) Kopierst und schaltest einfach den Rechner aus (stecker ziehen o.ä.) ist es klar, dass du Datenverlust hast Das ist ne Sache, die kannst du nicht einfach einem Defragmentierer zuschreiben

Zitat (bartek2k: 05.09.2006, 10:27)

Mythos aus DOS-Zeiten

Klingt aber irgendwie trotzdem logisch

Die NAME Methode eignet sich zum Beispiel direkt nach der Installation (da ua noch nicht allzuviele Prefretch (serschlagt mcih wenns falsch geschrieben ist) Dateien angelegt wurden, bzw nach dem Leeren des entsprechenden Ordners im %windir% sowie nach dem löschen der ROT13 Einträge in der Registry.

[Rika]

Zitat

ist es klar, dass du Datenverlust hast

Blödsinn. Die Originaldatei sollte ja noch einwandfrei vorhanden sein, was noch wichtiger ist, das Dateisystem sollte konsistent sein. Beim Defragmentieren wird auch erst ein neuer Cluster belegt, eine Kopie des Clusters dorthin erstellt und dann der Eintrag umgebogen. Das Problem ist, daß du ersteres und letzterer lieber nicht ohne vorherigen Anmeldung machen solltest, denn wenn's da zwischendrin abbricht, hast du mindestens ein Konsistentproblem bzw. im letzteren Falle auch Datenverlust. Und eben weil O&O Defrag nicht ordentlich mit FSCTL_MOVE_FILE arbeitet, kann es passieren, daß zwischen der Abfrage "Ist der Cluster frei? bzw. gib mir 'nen freien Cluster" und dem Alloziieren des Cluster die Gefahr besteht, daß der Cluster anderwaltig belegt wird - und wird dann überschrieben.

Zitat

Die NAME Methode eignet sich zum Beispiel direkt nach der Installation

Nochmal: Sie eignet sich nirgends, weil sich das Dateisystem intern eh nicht für die Dateinamen interessiert. Ein Ordner ist eine Liste von Dateien mit numerischer Kennung und Typ, und der Name wird ermittelt, indem man die numerische Kennung in der MFT nachschaut. Ich wüßte nicht mal, wie man unter diesen Aspekt eine Sortierung sinnvoll definieren soll, geschweige dann daß eine solche Sortierung irgendeinen Effekt hätte.

Zitat

sowie nach dem löschen der ROT13 Einträge in der Registry.

Also wenn schon, dann solltest du Ironie deutlicher kennzeichnen.

[Stefan_der_held]

Zitat (Rika: 21.09.2006, 08:15)

Also wenn schon, dann solltest du Ironie deutlicher kennzeichnen.

Wo soll denn da die Ironie sein?

[sn00b]

ich verstehe immer noch nicht warum sich die NAME methode nicht eignen soll?

ist es nicht so das eine partition wie ein buch ist?
ein buch besteht aus kapiteln (verzeichnisse) die wiederum in absätze (unterverzeichnisse) aufgeteilt sind!
der eigentliche inhalt spiegelt natürlich die datein wieder!

je nach verwendungszweck des buches ist eine sortierung nach namen doch höchst sinvoll!
denn die sortierungsmethode sortiert die kapitel mit allen absätzen und den kompletten inhalt dieser in alphabetischer reinfolge! so ist es ja auch sinvoll, ich möchte kein buch haben wo die kapitel durcheinander gewirbelt sind und ich um es sinvoll zulesen erstmal von seite 35 auf seite 57 blättern muß und dann gehts bei seite 12 weiter.

ob gefragte methode nun bei jeder partition sinvoll ist weiß ich nicht, aber zumindest scheint sie mir bei einer z.b. musik-partition mehr als sinvoll! dann kann man getrost einen kompletten ordner (kapitel) kopieren, entfernen oder abspielen und die festplatte hat keinen erhöten aufwand, da betroffene daten hintereinander weg kommen.

sollte ich da was falsch verstanden haben bitte ich um ausführliche berichtigung!

zu der eigentlichen arbeitsweise von O&O kann ich nichts sagen, habe aber bisher auch noch nie irgendwelsche probleme gehabt!

@rika die antwort auf sandokans frage würde mich auch interessieren!

Rika sagte:

@Hirni: Es _kann_ passieren, d.h. nicht daß es auch passieren _muss_.

und das aus deinen mund, das verwundert mich doch jetzt sehr! <- ich denke du weißt worauf sich das bezieht, nimms mir nicht übel!

[Rika]

Zitat

Wo soll denn da die Ironie sein?

Nenn mich dumm, aber ich kenne keinen Ort in der Registry, wo Windows ROT13-kodierte Strings speichert oder wozu das gut sein sollte, geschweige daß irgendein Zusammenhang mit Dateisystemfragmentierung vorhanden wäre.

Zitat

denn die sortierungsmethode sortiert die kapitel mit allen absätzen und den kompletten inhalt dieser in alphabetischer reinfolge! so ist es ja auch sinvoll, ich möchte kein buch haben wo die kapitel durcheinander gewirbelt sind und ich um es sinvoll zulesen erstmal von seite 35 auf seite 57 blättern muß und dann gehts bei seite 12 weiter.

Nochmal: Es interessiert sich einen Scheibendreck für Namen, und nachschlagen, wo ein Kapitel ist, musst du sowieso.

Bei mir liegen im Hauptverzeichnis der Bootpartition die Dateien boot.ini, ntldr, cmldr, ntdetect.com und die Ordner "cmdcons" und "System Volume Information" sowie die versteckten MFT*-Einträge. Sie haben die IDs 7, 11, 1189, 12, 43 und 89. Im normalen Bootvorgang wird zuerst ntldr, dann boot.ini, ntdetect.com und der Rest gar nicht geladen. Eine Hinternanderordnung gemäß Namen ist da absolut sinnfrei, ebenso wie eine Sortierung nach IDs. Wie auch in so ziemlich jedem anderen Szenario.

Zitat

dann kann man getrost einen kompletten ordner (kapitel) kopieren, entfernen oder abspielen und die festplatte hat keinen erhöten aufwand, da betroffene daten hintereinander weg kommen.

Und dann fügt man eine Datei hinzu, die liegt dann widerum total woanders, und das Umsortieren erfordert dann wieder riesigen Aufwand. Sortierung nach letzterer Modifikation ist da ein wesentlich sinnvolleres Kriterium, da es die Änderungsvorgänge auf den Medium wiederspiegelt. Selten bis nie veränderte Dateien können zusammenhängend rumliegen, während sich oft änderne Dateien eher am Ende des Mediums und relativ frei voneinander sein sollten.

Zitat

und das aus deinen mund, das verwundert mich doch jetzt sehr!

Bei ordentlichen Defragmentierungsprogrammen, die ordentlich das NT Fragmentation API nutzen, kann nix schiefgehen, weil es Konsistenz und Transaktionssicherheit garantiert. Also warum die Datensicherheit sinnlos gefährden? Sehe ich nicht ein, zumal es wesentlich bessere Programme gibt, die es auch richtig machen.

[sn00b]

Zitat

Und dann fügt man eine Datei hinzu, die liegt dann widerum total woanders, und das Umsortieren erfordert dann wieder riesigen Aufwand. Sortierung nach letzterer Modifikation ist da ein wesentlich sinnvolleres Kriterium, da es die Änderungsvorgänge auf den Medium wiederspiegelt. Selten bis nie veränderte Dateien können zusammenhängend rumliegen, während sich oft änderne Dateien eher am Ende des Mediums und relativ frei voneinander sein sollten.

ja, aber selbiges trifft doch auch auf alle anderen defragmentierungsmethoden zu. wenn, ich z.b. ein programm häufig nutze, und dieses dann nicht mehr brauche (deinstalliere) müßte auch neu defragmentiert werden! ist der aufwand dann niedriger, als wenn ich es bei namen mache? natürlich sehe ich ein das bei einem datenträger wo viel geändert wird die namen-methode wenig sinn macht, aber bei einem musik-archiv wo es seltener zu änderungen kommt, würde ich es als sinvoll betrachten!
im übrigen nutze ich seit geraumer zeit nurnoch die windowsinterne defragmentierung und das geht auch ganz gut! da ja wie du schon sagst eh immer erst nachgeschaut wird wo betreffende datei sich befindet.
eigentlich müßte die art der defragmentierung je nach anwendungszweck variieren.

Dieser Beitrag wurde von Master.Max bearbeitet: 21. September 2006 - 12:03

[Graumagier]

Master.Max sagte:

aber bei einem musik-archiev wo es seltener zu änderungen kommt, würde ich es als sinvoll betrachten!

Wenn du die Musik stets nur alphabetisch hörst, naja. Bei Shuffle-Wiedergabe nicht. Und spürbar ist der Geschwindigkeitsunterschied sowieso nicht.

[sn00b]

ja das ist richtig! aber das würde auch wieder alle anderen defragmentierungs methoden betreffen!
aber bei namen hätte man dann den vorteil wenn man sie nacheinander abspielt, oder halt ein kompletten ordner auf seinen portablen player überspielt. das man den geschwindigkeitsvorteil, egal wie man defragmentiert, wirklich wahr nimmt ist ja auch nicht gerade der fall!

ich plädiere für freie wahl zur defragmentierungsmethode!

[Rika]

Zitat

wenn, ich z.b. ein programm häufig nutze, und dieses dann nicht mehr brauche (deinstalliere) müßte auch neu defragmentiert werden!

Und bei Sortierung nach letzter Änderung verursacht es eine geringere Fragmentierung, weil es ohnehin in einem Bereich liegt, der relativ unsortiert ist.

Zitat

aber bei einem musik-archiev wo es seltener zu änderungen kommt, würde ich es als sinvoll betrachten!

Warum? 'Ne typische Festplatte schafft über 100 Head-Seeks pro Sekunde, da ist es vollkommen ausreichend, wenn nur die Dateien zusammenhängend sind und einer zukünftige Fragmentierung vorgebeugt wird, indem man keine Lücken dazwischen lässt. Die Anordnung der Dateien innerhalb einer Kategorie ist da ziemlich belanglos, denn die Head-Seeks sind halt billig und durchgehenden Lesen ganzer Dateigruppen ist auch ziemlich unrealistisch, insbesondere weil auch Ordner meist wo ganz anders liegen (und liegen sollten).

Zitat

eigentlich müßte die art der defragmentierung je nach anwendungszweck variieren.

Optimierung auf Anwendungsszenarien lohnt sich nur, wenn diese ganz spezifisch sind, wie z.B. ein immer gleicher Bootvorgang - das ist dann das, was der Prefetch-Mechanismus mit der layout.ini macht.

Zitat

aber bei namen hätte man dann den vorteil wenn man sie nacheinander abspielt, oder halt ein kompletten ordner auf seinen portablen player überspielt.

Ja, wenn die Festplatte deutlich langsamer als die Übertragung wäre und sonst absolut nix im Dateisystem passieren würde. Sehr realistisch.

Dieser Beitrag wurde von Rika bearbeitet: 21. September 2006 - 12:06

[Stefan_der_held]

Zitat (Rika: 21.09.2006, 10:32)

Nenn mich dumm, aber ich kenne keinen Ort in der Registry, wo Windows ROT13-kodierte Strings speichert oder wozu das gut sein sollte, geschweige daß irgendein Zusammenhang mit Dateisystemfragmentierung vorhanden wäre.

Ja ich hab dich auch lieb

Mom sinds recht wenige Einträge (normalerweise sind da bis zu 100 Einträge und mehr drin). Aber die lösche ich ca 1-2 mal pro Monat. Erkennbar sind diese eigentlich an den "HRZR" am beginn des schlüssels.

Hier speichert Windows nochmal alles was wann wo ausgeführt wurde. Deswegen ist nach dem Löschen eigentlich auch die "Modified" bzw "accres" Methode nicht sonderlich effektiv.

Das dumme ist aber wenn man se nciht löscht, wächst diese Liste und müllt eigentlich sinnloser weise die Registry zu. Denn was interessierts mich was ich am 13.12.2004 aufgerufen habe?

Dieser Beitrag wurde von Stefan_der_held bearbeitet: 21. September 2006 - 12:16

[sn00b]

Zitat

Und bei Sortierung nach letzter Änderung verursacht es eine geringere Fragmentierung, weil es ohnehin in einem Bereich liegt, der relativ unsortiert ist.

das ist es ja was ich nicht ganz verstehe, wenn ich ein programm nutze werden ja nicht alle datein die das programm benötigt auch geandert! das heißt wenn ich es löche entstehen ja sowohl in der mitte (oder am anfang oder wo auch immer lücken) und am ende ja sowieso, weil dort halt die datein des programmes liegen die geändert werden.

Zitat

Ja, wenn die Festplatte deutlich langsamer als die Übertragung wäre und sonst absolut nix im Dateisystem passieren würde. Sehr realistisch.

hmm, mal schauen ob ich noch irgendwo so ne uralt platte finde!

[Stefan_der_held]

@ Master.Max:

Wenn du defragmentierst (egal wie) und du löscht ein Programm oder eine Datei läufst du immer bei NTFS und anderen MS- Fat's gefahr, Lücken in den Speicher zu reißen.

[sn00b]

ja, das wollte ich ja damit ausdrücken!

[Rika]

Zitat

Ja ich hab dich auch lieb

Das hat aber nix mit ROT13 zu tun. Vielleicht ist "Rot" als Attribut und 13 als Zähler gemeint, aber selbst das ergibt wenig Sinn.

Zitat

Hier speichert Windows nochmal alles was wann wo ausgeführt wurde. Deswegen ist nach dem Löschen eigentlich auch die "Modified" bzw "accres" Methode nicht sonderlich effektiv.

Die Registry gilt quasi permanent als Modified und ist im laufenden Betrieb meist sowieso gelockt, wird also wohl kaum beim Defragmentieren Beachtung finden. Sie neigt aber auch nicht zur Fragmentierung.

Zitat

Das dumme ist aber wenn man se nciht löscht, wächst diese Liste und müllt eigentlich sinnloser weise die Registry zu. Denn was interessierts mich was ich am 13.12.2004 aufgerufen habe?

Mal ganz davon abgesehen, daß ich nicht erkennen kann, wo denn die Liste überhaupt zu finden ist, würde ich mal sagen, daß die in der benutzerspezifischen Registry liegt und damit kaum das System zumüllt. Und zur Fragmentierung führt das auch nicht, denn sie ist viel zu klein, und die Registry ist als leicht balancierte Hash-Tabelle von B+-Baum-Blöcken organisiert, wächst also nur sehr langsam (und zwar immer nur auf 2er-Potenzen bzw. eventuelle mit halben Zwischenergebnissen).

Zitat

wenn ich ein programm nutze werden ja nicht alle datein die das programm benötigt auch geandert

Eher: gar keine.

Zitat

das heißt wenn ich es löche entstehen ja sowohl in der mitte (oder am anfang oder wo auch immer lücken) und am ende ja sowieso, weil dort halt die datein des programmes liegen die geändert werden.

Richtig. Defragmentierungsprogramme können nicht weissagen, daß du vielleicht nach 'nem Jahr ein Programm wieder löschst und damit in der Kategorie der selten ändernenden Dateien dann eine Lücke auftritt. Das Ergebnis ist allerdings progessiv, d.h. die zu erwartende Fragmentierung und der Aufwand zur Defragmentierung ist minimal und das Ergebnis nährt sich zunehmend dem theoretischen Weissager-Optimum an. Die erste Fragmentierung dauert vielleicht noch lange, die späteren werden immer kürzer und irgendwann defragmentiert man eigentlich nur noch die letzten paar minimalen Änderungen.
Das ist im Prinzip auch die Funktionsweise der Defragmentierung noch letztere Änderung: Vorbeugen gegenüber zukünftiger Fragmentierung, statt sinnlose Perfektionierung nach irrelevanten Kriterien, die in Zukunft eher zu höherer Fragmentierung führen.