Re: Wie kann ich Dateien im Verzeichnis physisch sortieren (Tool für mp3-Player)

[Ralf Gesellensetter]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20130915/5171b87c/attachment.sig>