Hallo Jan-Benedict Am 15.09.2013 12:10, schrieb Jan-Benedict Glaw: > Dateien sin dim Dateisystem _nie_ sortiert. Sie liegen da einfach und > kommen, ggf., zufällig, in der Reihenfolge aus den > opendir()/readdir()/closedir()-Aufrufen heraus.
Mh, das mag für native Linux-fs wie ext3 gelten (darüber weiß ich zu wenig). Aus Sicht des Kernels mag es vielleicht auch so aussehen, da ja das spezifische Filesystem durch das entsprechende Abstraktions-Layer verdeckt ist. Da ich aber in den 90ern selbst Routinen programmieren musste, um an die verlorenen Daten auf meiner 40MB-Vortex-Platte zu kommen, kenne ich den physischen Aufbau von FAT-Systemen recht gut. Und da werden die Dateien von "ls -f" (bzw. von readdir() ) genau in der Reihenfolge ausgelesen, wie sie aufgelistet sind. Das ist (anders als z.B. die Traversion eines Baumes) eindeutig. Natürlich wird im Verzeichnis der Platz von gelöschten Dateien neu belegt, so dass nach Create A; Create B; Delete A; Create C; Create A die willkürliche Reihenfolge "C B A" lauten müsste. ... > > `ls' und Co. zeigen die Dateien sortiert an, weil sie sie _selbst_ > nach Dateinamen sortieren. Und genau dazu hat es in der Firmware dieser Player offenbar nicht mehr gereicht. > > Das Rippen von CDs hab' ich bisher immer so gemacht, daß im Dateinamen > alle Infos in einer sinnvollen Reihenfolge auftauchen. Daß also z.B. > bei einer Werk mit mehreren CDs erst die CD-Nummer (ggf. mit > hinreichend viele führenden Nullen), dann die Track-Nummer (ebenso mit > genügned vielen führenden Nullen) etc. im Namen auftaucht. Genau, z.B. 01_Track1v2 02_Track2v2 Ich habe schon einige Erfahrung mit Playern, und es ist wirklich sehr vermessen von den Entwicklern der Firmware, anzunehmen, dass die Dateien in der richtigen Reihenfolge im Verzeichnis liegen. Dass es nicht am ID3-Tag liegt, konnte ich allein daher sehen, dass hin und herkopieren der Dateien das Problem gelöst hat. Wenn man bedenkt, dass der iRiver E150 soger eine interne "Datenbank" führt, in der man sogar Songs bewerten kann oder nach Genre, Album oder Interpret aufrufen, scheint es mir unwahrscheinlich, dass die Sortierung vergessen wurde. Vielmehr könnte ich mir vorstellen, dass es ein unbekanntes (weil in 99.9% aller Fälle irrelevantes) Feature von Windows ist, Dateien immer sortiert zu kopieren. Eine Lücke beim Reverse Engineering des FAT-Systems? (Was zu beweisen wäre). > > Daß MP3-Player die Dateien wirklich unsortiert (wie sie aus dem > readdir()-Aufruf kommen) abspielen, hab' ich allerdings noch nicht > gesehen. Was ähnliche Effekte haben kann, geht aus dieser Beobachtung > hervor: Wenn id3-Tags (oder entsprechende, für den Player parsbare > Informationen in anderen Dateitypen) vorhanden sind, dann werden > primar diese ausgewertet. Danach wird der Dateiname, oft anstatt des > Songtitels, herangezogen. Mag sein, aber hin und herkopieren würde daran nichts ändern. > > Falls also Deine Dateien teilweise Tags enthalten, andere nicht, oder > diese Tags nicht einheitlich sind, dann kann auch das dazu führen, daß > die Abspiel-Reihenfolge fritten ist... Stimmt für manche anderen Player - IIRC auch bei Mediatomb (uPNP server) > > > Wenn Du Dateien in der Reihenfolge auf das Ziel-Medium kopieren > möchtest, wie sie (alphabetisch sortiert) sinnvoll wäre, dann beim > cp'ieren mit globbing dafür sorgen, daß `cp' schon eine entsprechende > Liste bekommt: Statt `cp . /mnt/mp3player' dann eben `cp * > /mnt/mp3player' nehmen. Das scheint tatsächlich zu klappen, auch in der 2. Ebene z.B. cp -rv */* /media/e150/ Sobald man aber grafische Oberflächen wie mc, krusader, dolphin usw. nutzt, hat man hier verloren. Das QuellFS ist übrigens ext4. Und ein ls -f gibt die Dateien genau so aus, wie sie von "cp -v" kopiert werden, wobei irgendo zwischendrin auch noch "." und ".." verstreut liegen. Natürlich wurden die Dateien in aufsteigender Reihenfolge erzeugt (gerippt), so dass ich auch hier dem FS ext4 unterstelle, die Reihenfolge nicht zu berücksichtigen. (Was in 99.9% der Fälle okay ist, und vermutlich schneller ist). Dazu habe ich diese Bugs gefunden: https://rt.cpan.org/Public/Bug/Display.html?id=7448 aus Sicht eines Perl-Entwicklers und http://stackoverflow.com/questions/7598199/what-guarantees-are-given-by-smb-and-ext3-regarding-order-of-file-writes aus Sicht eines Samba-Users. Als "Reperatur"-Tool kommen m.E. Programme in Frage, die bereits jetzt speziell FAT-Partitionen mit low-level-Zugriffen manipulieren, z.B. testdisk oder mtools (Kandidaten für ein Feature-Request). Ciao Ralf > > MfG, JBG
signature.asc
Description: OpenPGP digital signature
-- Linux mailing list [email protected] subscribe/unsubscribe: http://lug-owl.de/mailman/listinfo/linux Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo
