# Zufällige Dateireihenfolge beim Kopieren auf USB-Stick

## astaecker

Moin,

mein Vater hat sich gerade einen digitalen Bilderrahmen gekauft, den man per USB-Stick oder Speicherkarte mit Bilder füttern kann. Er will das Gerät nutzen, um die Urlaubsbildern den Freunden zu zeigen, um sich die Papierfotos zu sparen.

Leider haben wir das Problem, dass beim Befüllen des USB-Sticks mit Daten die Dateien in einer zufälligen Reihenfolge kopiert werden. Unter KDE4 kann man die willkürliche Reihenfolge gut mitverfolgen. Steckt man den Stick in den Rechner, sortiert er die Bilder automatisch richtig nach Namen, der Bilderrahmen aber nicht. 

Ein Test unter Windows zeigte das Problem nicht. Ich habe es dann nochmal unter Linux versucht, diesmal habe ich den Stick manuell gemountet. Kein Erfolg. Auch die Option "sync" hat nicht geholfen.

Wisst ihr weiter ?

----------

## l3u

Ich würde mal versuchen, die Bilder (per Script) einzeln zu kopieren. Also z. B. sowas wie

```
for bild in $(ls -1); do

        cp $bild /media/...;

done
```

funktioniert, wenn keine Leerzeichen in den Dateinamen sind. Ansonsten find -print0 ... oder sowas.

----------

## astaecker

Klingt gut, aber das kann ich meinem Vater nicht zumuten. Ich muss Linux dazu bekommen, dass er die Daten in alphabetischer anstatt in zufälliger Reihenfolge überträgt.

----------

## l3u

Das wird wohl anders nicht gehen … aber ich lasse mich gern eines Besseren belehren!

----------

## ChrisJumper

Mein Bauchgefühl sagt das da was nicht stimmt.

Probiere doch mal aus ob dieser Bilderrahmen die Daten vielleicht nicht doch nach einem anderen Kriterium sortiert "Namen" oder die Position auf dem Datenträger. Oder ob die Methode von l3u überhaupt zum Erfolg führt.

Vielleicht sortiert der Rahmen die Bilder auch nach Metadaten oder dem Zeitpunkt der Erstellung oder sowas..?

----------

## astaecker

Ich habe die Bilder nun mal nach l3u per Hand in der richtigen Reihenfolge kopiert und so werden sie auch korrekt angezeigt. 

Im Gerät selber lässt sich die Reihenfolge nicht einstellen. Da ist nur ein sehr rudimentärer Dateimanager drin. Auch eine Sortierung nach Erstelldatum wird ist es nicht, da die Urlaubsbilder nicht umsortiert worden sind. Auch gibt es keine neuere Firmware.

Ich werde es morgen mal mit einem anderen Linux probieren. Aber ansonsten weiß ich echt nicht mehr weiter.

P.S.: Beim Bilderrahmen handelt es sich um den Intenso 7" Photostar.

----------

## Hollowman

Dann pack das Script auf den Rechner und leg nen Alias an.

Dann machste irgendwo nen Ordner hin wo er die Bilder die auf den Rahmen sollen hin kopieren kann. Dann brauch er nur noch das Script aufrufen und schon hat er die Bilder auf dem Rahmen. Das sollte er eigentlich schaffen. Kannst ihm ja nen eintrag ins KDE/Gnome/usw. Menü machen.

Sebastian

----------

## l3u

Dann aber besser so (dann geht's auch mit Leerzeichen):

```
ls -1 | while read filename; do

        cp "$filename" ...

done
```

----------

## Fauli

Ein

```
cp * /media/... 
```

reicht aber auch, denn die Shell sortiert die Dateinamen, die auf * passen, ja schon automatisch alphabetisch.

Damit die Standard-KDE-Kopierfunktion die Dateien in der richtigen Reihenfolge kopiert, müsstest du wahrscheinlich ein Dateisystem benutzen, dessen readdir-Funktion die Dateinamen sortiert zurückliefert. Ich bin mir aber nicht sicher, ob überhaupt eins der von Linux unterstützten Dateisysteme das macht.

Oder du benutzt ein anderes Programm (mit GUI), das die Dateinamen vor dem Kopieren sortiert.

----------

## 69719

Das Problem könnte gelöst werden indem man den USB Stick vor dem kopieren formatiert, so schreibt er die Daten anschließend hintereinander in das Dateisystem. Mit cp sollte das beschreiben dann in sortierter Reihenfolge stattfinden. Ob KDE da mitspielt weiß ich nicht. Testen kannst du es mit 

```
ls -f
```

.

----------

## EOF

Ich nehme an der stick ist fat/fat32 formatiert. Du musst einfach die fat-tabelle mit

fatsort /dev/... 

sortieren und schon sind die Bilder sortiert.

Link:

http://fatsort.berlios.de/

----------

## astaecker

Moin, da bin ich wieder. Hatte beruflich so einiges zu tun gehabt.

Aber ich habe so einige Sachen getestet:

* Kubuntu 8.04 (KDE 3.5) hat das Problem

* Kubuntu 8.10 (KDE 4.1) hat das Problem

* Ubuntu 8.10 (Gnome) hat das Problem nicht

* Gentoo Gnome hat das Problem nicht

* fatsort behebt das Problem

Also scheinbar überträgt Nautilus sortiert die Daten, Dolphin hingegen nicht. Im KDE Bugzilla konnte ich keinen entsprechenden Bericht finden. Werde wohl mal einen schreiben. Bis dahin werde ich fatsort einsetzen.

Vielen Dank an alle für die guten Vorschläge.

----------

## l3u

Naja, ob das ein „Bug“ ist, darüber läßt sich streiten … schließlich heißt es ja „Kopieren“, und das ist das, was es tut – nach dem Kopieren sind alle Dateien von A in B verfügbar. Es hat niemand gesagt, daß die in einer gewissen Reihenfolge kopiert werden …

----------

## EOF

 *arlsair wrote:*   

> Moin, da bin ich wieder. Hatte beruflich so einiges zu tun gehabt.
> 
> Aber ich habe so einige Sachen getestet:
> 
> * Kubuntu 8.04 (KDE 3.5) hat das Problem
> ...

 

Ich denke dsaProblem ist eher der Bilderrahmen, der die Bilder nicht in sortierter Reihenfolge ausgeben kann. Es gibt kein Grund für die oben genannten Programme unnötige Schreiboperationen auszuführen. Jedenfalls habe ich das gleiche Problem mit meinem mp3-player gehabt. Ich hatte eine udev regel so modifiziert, dass beim unmount fatsort ausgeführt wird. Leider habe ich zwischenzeitlich das system neu aufgesetzt ...

----------

## astaecker

 *l3u wrote:*   

> Naja, ob das ein „Bug“ ist, darüber läßt sich streiten … schließlich heißt es ja „Kopieren“, und das ist das, was es tut – nach dem Kopieren sind alle Dateien von A in B verfügbar. Es hat niemand gesagt, daß die in einer gewissen Reihenfolge kopiert werden …

 

Nun, es ist doch ein unerwartetes Verhalten. Ich werde den Bericht aber wohl nicht als Bug, sondern als Wunsch deklarieren. Vielleicht hat es ja starke Auswirkungen auf die Performance, weshalb auf die Sortierung verzichtet wurde.

----------

## EOF

 *arlsair wrote:*   

>  *l3u wrote:*   Naja, ob das ein „Bug“ ist, darüber läßt sich streiten … schließlich heißt es ja „Kopieren“, und das ist das, was es tut – nach dem Kopieren sind alle Dateien von A in B verfügbar. Es hat niemand gesagt, daß die in einer gewissen Reihenfolge kopiert werden … 
> 
> Nun, es ist doch ein unerwartetes Verhalten. Ich werde den Bericht aber wohl nicht als Bug, sondern als Wunsch deklarieren. Vielleicht hat es ja starke Auswirkungen auf die Performance, weshalb auf die Sortierung verzichtet wurde.

 

Es ist doch klar, dass man für einen digitalen Bilderrahmen eine möglichst günstige Hardware nimmt. Sortieren kostet Strom, Speicher, CPU-Power und die effiziente Programmierung auf einem so schwachen System kann kompliziert werden. Ich denke dein Vater hätte besser ein gebrauchtes Nokia 770 gekauft, was man auch als Bilderrahmen zweckentfremden könnte  :Smile: .

----------

## astaecker

Ja, m Nachhinein hätte man sich vielleicht solche Gedanken machen können. Aber da ich das Problem selbst nicht kannte - geschweige denn mein Vater - , legt man auf so etwas vorab kein Augenmerk.

Das Nokia 770 ist zwar wirklich mobil (hat einen Akku), aber dafür keinen 7 Zoll Bildschirm und auch keine Fernbedienung.

Ich werde dennoch mal bei KDE an die Tür klopfen wegen der Sortierung beim Kopieren, da ich es zumindestens von manchen anderen Linux Projekten (z.B. ACPI Subsystem) her kenne, dass man alles unterstützen möchte. Ob nun gut gemachte Hardware oder nicht.

----------

## 69719

 *arlsair wrote:*   

> Ja, m Nachhinein hätte man sich vielleicht solche Gedanken machen können. Aber da ich das Problem selbst nicht kannte - geschweige denn mein Vater - , legt man auf so etwas vorab kein Augenmerk.
> 
> Das Nokia 770 ist zwar wirklich mobil (hat einen Akku), aber dafür keinen 7 Zoll Bildschirm und auch keine Fernbedienung.
> 
> Ich werde dennoch mal bei KDE an die Tür klopfen wegen der Sortierung beim Kopieren, da ich es zumindestens von manchen anderen Linux Projekten (z.B. ACPI Subsystem) her kenne, dass man alles unterstützen möchte. Ob nun gut gemachte Hardware oder nicht.

 

Naja, sortiert kopieren ist unnötige CPU Belastung, von daher keine gute Idee. Da würde ich das ko**** bekommen wenn ich dann mit dem Konqueror auf arbeit Dateien kopiere und das sind nicht wenige. Mit den ganzen Unterordnern, da kommen schon ein paar Millionen zusammen.

----------

## astaecker

Allerdings ist das Sortieren eine Sache, die man nur einmal vor dem Kopieren macht. Die Transferrate ist also davon nicht betroffen.

Ich habe eben mal die Zeit gemessen, die ein Java Programm braucht, um ein Verzeichnis mit 10.000 Dateien zu sortieren: 56 Millisekunden. Bei 1 Million Datei (in einem Verzeichnis) wäre das dann hochgerechnet gerade mal 5,6 Sekunden. Finde ich nun gerade so viel. Da die Daten eh seriell übertragen werden, kann man die Berechnung parallel zur Übertragung machen, so dass die Sortierung wohl nicht weiter auffällt.

----------

## oscarwild

 *arlsair wrote:*   

> Allerdings ist das Sortieren eine Sache, die man nur einmal vor dem Kopieren macht.

 

Naja, aber nach welchem Kriterium? Es ist völlig willkürlich, dass der Dateiname als Kriterium dienen soll. Genau so logisch/unlogisch wäre es, jedes beliebige andere Attribut dafür zu verwenden, also Größe, Erstellungsdatum, Modifikationsdatum, ...

----------

## astaecker

 *oscarwild wrote:*   

> Naja, aber nach welchem Kriterium? Es ist völlig willkürlich, dass der Dateiname als Kriterium dienen soll. Genau so logisch/unlogisch wäre es, jedes beliebige andere Attribut dafür zu verwenden, also Größe, Erstellungsdatum, Modifikationsdatum, ...

 

So willkürlich ist das nicht. Zumindestens Windows und Gnome kopieren die Daten sortiert nach Dateinamen. Und auch KDE zeigt alle Daten in Dolphin & Co erstmal sortiert nach Dateinamen an.

----------

## oscarwild

 *arlsair wrote:*   

>  *oscarwild wrote:*   Naja, aber nach welchem Kriterium? Es ist völlig willkürlich, dass der Dateiname als Kriterium dienen soll. Genau so logisch/unlogisch wäre es, jedes beliebige andere Attribut dafür zu verwenden, also Größe, Erstellungsdatum, Modifikationsdatum, ... 
> 
> So willkürlich ist das nicht. Zumindestens Windows und Gnome kopieren die Daten sortiert nach Dateinamen. Und auch KDE zeigt alle Daten in Dolphin & Co erstmal sortiert nach Dateinamen an.

 

Bzgl. der Anzeige nicht - ist schließlich ja für einen menschlichen Benutzer gedacht, der sich im einfachsten Fall am Dateinamen orientiert (abgesehen davon, dass die Standard-Sortierreihenfolge ggf. einstellbar ist). Beim Kopieren stellt sich die Frage normalerweise aber nicht - das System kann ja nicht ahnen, wie die Kopie benutzt wird, bzw. wird der nächste Dateimanager den Inhalt ohnehin nach dem jeweiligen Benutzerwunsch anordnen.

Dass der Bilderrahmen diese Möglichkeit nicht bietet, ist ärgerlich, aber ich halte es für falsch, dies per Workaround am Dateimanager kompensieren zu wollen: der nächste Anwender sortiert seine Bilder nicht nach Namen, und möchte sie vom Bilderrahmen in der Reihenfolge der Erstellung angezeigt bekommen. Stammen die Bilder nun nicht gerade von einer Digitalkamera, die üblicherweise aufsteigend durchnummeriert, hat er durch eine alphabetische Sortierung das gleich Problem wie Du - bei inkompatiblem Workaround. Zudem ist eine alphabetische Sortierung auf den zweiten Blick auch gar nicht so eindeutig (Klassiker z.B.: kommt die Datei "Bild9.jpg" vor oder nach "Bild10.jpg"?).

----------

## 69719

 *arlsair wrote:*   

> Allerdings ist das Sortieren eine Sache, die man nur einmal vor dem Kopieren macht. Die Transferrate ist also davon nicht betroffen.
> 
> Ich habe eben mal die Zeit gemessen, die ein Java Programm braucht, um ein Verzeichnis mit 10.000 Dateien zu sortieren: 56 Millisekunden. Bei 1 Million Datei (in einem Verzeichnis) wäre das dann hochgerechnet gerade mal 5,6 Sekunden. Finde ich nun gerade so viel. Da die Daten eh seriell übertragen werden, kann man die Berechnung parallel zur Übertragung machen, so dass die Sortierung wohl nicht weiter auffällt.

 

Nicht gecachtes Filesystem, sortiert

```

escor@mars ~/tmp/test $ time ls -ls | sort | wc -l

131917

real    1m12.841s

user    0m12.683s

sys     0m2.935s

```

Gecachtes Filesystem, sortiert

```

escor@mars ~/tmp/test $ time ls -ls | sort | wc -l

131917

real    0m17.605s

user    0m12.644s

sys     0m1.703s

```

Gecachtes Filesystem, nicht sortiert

```

escor@mars ~/tmp/test $ time ls -ls | wc -l

131917

real    0m7.056s

user    0m3.155s

sys     0m1.544s

```

Bei dem Ergebnissen, welches gerademal für 131916 Dateien durchgefühert wurde, sind schon ganz schöne unterschiede zu erkennen. Beim Konqueror würde dies auch nicht schneller ablaufen.

----------

## astaecker

 *oscarwild wrote:*   

> Bzgl. der Anzeige nicht - ist schließlich ja für einen menschlichen Benutzer gedacht, der sich im einfachsten Fall am Dateinamen orientiert (abgesehen davon, dass die Standard-Sortierreihenfolge ggf. einstellbar ist). Beim Kopieren stellt sich die Frage normalerweise aber nicht - das System kann ja nicht ahnen, wie die Kopie benutzt wird, bzw. wird der nächste Dateimanager den Inhalt ohnehin nach dem jeweiligen Benutzerwunsch anordnen.
> 
> Dass der Bilderrahmen diese Möglichkeit nicht bietet, ist ärgerlich, aber ich halte es für falsch, dies per Workaround am Dateimanager kompensieren zu wollen: der nächste Anwender sortiert seine Bilder nicht nach Namen, und möchte sie vom Bilderrahmen in der Reihenfolge der Erstellung angezeigt bekommen. Stammen die Bilder nun nicht gerade von einer Digitalkamera, die üblicherweise aufsteigend durchnummeriert, hat er durch eine alphabetische Sortierung das gleich Problem wie Du - bei inkompatiblem Workaround. Zudem ist eine alphabetische Sortierung auf den zweiten Blick auch gar nicht so eindeutig (Klassiker z.B.: kommt die Datei "Bild9.jpg" vor oder nach "Bild10.jpg"?).

 

Der "nächste Dateimanager" sortiert eh die Daten, ob sie nun alphabetisch vorliegen oder nicht. Das zeigt sich ja daran, dass die Daten vom unsortierten Stick immer sortiert angezeigt werden. Die Ausnahme bildet hier nur die Hardware, die überhaupt keine Sortierfunktion hat. Also ergibt sich, dass das Sortieren der Daten bei Kopieren (oder nicht), überhaupt keine Auswirkungen auf die Anzeige bei einem normalen Dateimanager hat. Der Dateimanager ist beim Anzeigen der Daten durch das Sortieren weder langsamer  noch muss er irgendwelche Workarounds (beim Anzeigen) einbauen.

Die Änderungen an Dolphin, um beim Kopieren die Daten zu sortieren sind wohl eher minimal, da zumindestens QT entsprechende Funktionen mitbringt. Wie gezeigt, wird die Performance nicht merklich leiden.

Letztlich bleiben die Fragen, ob man überhaupt und wenn ja, wie man sortieren sollte. Meine Position hier ist, dass man mehr Geräte (so wie vorgesehen) damit unterstützen würde und die Sortierung nach Dateiname der Quasi-Standard ist. Sie ist auch in Geräte (wie Digitalkameras) sehr verbreitet.

----------

## oscarwild

 *arlsair wrote:*   

> Der "nächste Dateimanager" sortiert eh die Daten, ob sie nun alphabetisch vorliegen oder nicht. Das zeigt sich ja daran, dass die Daten vom unsortierten Stick immer sortiert angezeigt werden. Die Ausnahme bildet hier nur die Hardware, die überhaupt keine Sortierfunktion hat. Also ergibt sich, dass das Sortieren der Daten bei Kopieren (oder nicht), überhaupt keine Auswirkungen auf die Anzeige bei einem normalen Dateimanager hat. Der Dateimanager ist beim Anzeigen der Daten durch das Sortieren weder langsamer  noch muss er irgendwelche Workarounds (beim Anzeigen) einbauen.

 

Korrekt. Und daher ist es auch völlig sinnlos, die Dateien sortiert zu speichern.

 *arlsair wrote:*   

> Die Änderungen an Dolphin, um beim Kopieren die Daten zu sortieren sind wohl eher minimal, da zumindestens QT entsprechende Funktionen mitbringt. Wie gezeigt, wird die Performance nicht merklich leiden.

 

Dadurch wird die Änderung aber nicht sinnvoller...

 *arlsair wrote:*   

> und die Sortierung nach Dateiname der Quasi-Standard ist.

 

Ich vertehe Dein Anliegen. Es handelt sich trotzdem definitiv nicht um einen "Standard". Wenn einige Dateimanger die Dateien so kopieren, dass es für Deinen Bilderrahmen passt, ist dies ein zufälliger Nebeneffekt des zugrundeliegenden Kopieralgorithmus, keinesfalls ein geplanter Anwendungsfall, noch eine Annahme, die eine dritte Applikation treffen darf. Wenn Dein Bilderrahmen sich auf ein Verhalten stützt, das z.B. sich mit dem nächsten Update des verwendeten Dateimanagers ggf. komplett ändern kann, ist das lediglich ein Beispiel dafür, wie man Software gerade NICHT entwickeln sollte.

 *arlsair wrote:*   

> Sie ist auch in Geräte (wie Digitalkameras) sehr verbreitet.

 

Nein. Die Applikation auf Deinem PC beinhaltet den Kopieralgorithmus. Die Kamera liefert die Daten lediglich in der angeforderten Reihenfolge.

----------

## ChrisJumper

Natürlich ist das keine geeignete Funktion für den Konquerer und Co.

Aber wenn ich mir das so ansehe könnte man solche Funktionen durchaus da implementieren wo sie Sinn machen. Etwa beim Amarok, wenn er Playlisten verwaltet und eine Kopie dessen auf den Mp3 Player anbietet.

Für Bilder könnte man eine entsprechende Funktion in Gwenview verwenden.

Wie man Sortieren sollte bestimmt dann der User beim Erstellen der "Playliste".

----------

## Necoro

 *EOF wrote:*   

> http://fatsort.berlios.de/

 

Hat mir mein eix gerade angezeigt: Ist jetzt auch im Portage-Tree  :Smile: 

----------

