Backend - Dateiverwaltung - Upload / Datum bei Multi-Upload

[idea-tec]

Und nun würde ich gerne zum eigentlichen Problem zurück:
Upload funktioniert, Zeit wird (egal wie das nun passieren wird, mittels usleep() oder Counter) enstprechend gesetzt und ist somit Unique.

Bleibt aber immer noch, die Tatsache, dass der Apache die Dateien nicht sortiert aus dem Ordner ausliest.
Dies leuchtet mir nicht ein, da ich mir nicht vorstellen kann (will!), dass sync() den Ordner nicht alphabetisch sortiert ausliest, das würde doch allem widersprechen, was man so weiß.

Frage also: Ist das ein Bug in sync()?

Gleich die nächste Frage: Wieso trägt man die Dateien nicht gleich beim Upload in die DB ein (außer Performance)?
Das würde so ziemlich alle Probleme lösen und man könnte den Key auch gleich noch verwenden um (nur zur Sicherheit) die Sekunden der Uhrzeit entsprechend nach oben zu addieren. Denn auch hier dürfte gelten: es ist kaum anzunehmen, dass ein Anwender innerhalb von weniger als 11 Sekunden einen weiteren Einzelupload vornimmt.

Dadurch hätte man eine weitere, saubere, vom Dateinamen unabhängige Möglichkeit Dateien zum Beispiel in Galerien zeitlich sortiert anzuzeigen, ohne dass man zusätzlich auf den Dateinamen sehen muss. Was beim derzeitigen Status beim besten Willen nicht möglich ist.

[kummer]

Das ist Quatsch ... weil es bei der Anzeige NACH dem Upload immer auf die Performance des Servers ankommt, weil nämlich die File-Übersicht angezeigt wird. Mit allen Informationen, Thumbnails, etc...
Und die meisten haben hier eine 100 als Anzahl der anzuzeigenden Bilder eingestellt
Vermisch doch also bitte nicht das eine mit dem anderen, und sorry, wenn ich mich dir gegenüber nicht DAU-mäßig genug ausgedrückt habe, da ich davon ausgegangen bin, dass du weisst was ich meine.

ich stelle fest, dass inzwischen der rest an höflichkeit offenbar deiner fortschreitenden demenz zum opfer gefallen ist. wenn du das so möchtest, dann läuft bei dir usleep schneller ab, weil du so ungemein leistungsfähige server hast. klar. logisch. wie konnte ich das vergessen.

@Dein Vorschlag:
der birgt Risiken, wobei die vernachlässigbar sind, da kaum anzunehmen ist, dass jemand innerhalb von 10 Sekunden ein weiteres einzelbild hochlädt.

das hast du recht. mindestens halb. oder sagen wir ein viertel. nö, eigentlich gar nicht, wenn man es recht bedenkt. (a) in 10 sekunden kann viel geschehen. insofern ist das riskio nicht gering. die eintretenswahrscheinlichkeit steigt mit der anzahl nutzer. ist also eher eine frage des wann und nicht des ob. (b) das risiko ist deiner lösung inhärent. mein vorschlag würde einfach ein seltsames und leistungsreduzierendes entwurfsmuster beseitigen. und (c) wo liegt das risiko? oder die chance? gleichzeitigkeit ist sinnvoll nicht zu vermeiden. wenn darin ein risiko besteht, dann ist schlicht und ergreifend der ansatz falsch.

[kummer]

UBleibt aber immer noch, die Tatsache, dass der Apache die Dateien nicht sortiert aus dem Ordner ausliest.
Dies leuchtet mir nicht ein, da ich mir nicht vorstellen kann (will!), dass sync() den Ordner nicht alphabetisch sortiert ausliest, das würde doch allem widersprechen, was man so weiß.

das ist kein bug. mindestens nicht auf seiten des servers. das ist vollkommen richtig so. wenn du es sortiert haben willst, musst du entweder sortieren (nach einem kriterium, dass du halt festlegen musst) oder du liest es gezielt alphabetisch sortiert aus dem dateisystem. der server gibt sie so zurück, wie sie im dateisystem vorliegen.

[idea-tec]

...dann ist schlicht und ergreifend der ansatz falsch.

Es steht mir nicht zu die These in den Raum zu stellen, dass der aktuell vorhandene Ansatz innerhalb von Contenido ein falscher ist.

Was mir (und jedem anderen auch) jedoch zusteht ist die berechtigte Frage:
- Wieso erhalten 2-10 Dateien bei einem Multi-Upload die gleiche Uhrzeit?

Mir ist bei dieser Frage durchaus klar, dass kleine Dateien bei entsprechender Verbindung ebenfalls die gleiche Systemzeit haben. ABER: Nach dieser wird in der Regel nicht ausgelesen.
Da wir innerhalb von Contenido jedoch ein entsprechendes Feld in der Tabelle haben, das ja eh befüllt wird, kann man dieses doch auch sinnvoll nutzbar machen. Verhindert wird dies jedoch durch die Einträge in die DB mittels "create()" da die Einträge nicht der Anzeige in der Dateiübersicht, noch der Reihenfolge der Auswahl im Uploadformular entspricht.

Eine entsprechende Anpassung würde (außer man möchte das Feld created auf timestamp umändern) nichts an den bisherigen Funktionen, Modulen, Sortierungen ändern. Das ist damit sogar rückwärtskompatibel.

[kummer]

Dadurch hätte man eine weitere, saubere, vom Dateinamen unabhängige Möglichkeit Dateien zum Beispiel in Galerien zeitlich sortiert anzuzeigen, ohne dass man zusätzlich auf den Dateinamen sehen muss.

vom dateinamen unabhängig zeitlich sortiert? also wenn du dich DAU-mässig (zitat von dir) ausdrücken willst, dann hast du das an dieser stelle geschafft. aber zeitlich ist immerhin klar. vielleicht ist dir schon aufgefallen, dass der primärschlüssel eindeutig ist. was bedeutet, dass er im zeitlichen verlauf zunehmen muss. hmm, ist wohl nicht eindeutig genug. deshalb: sortierst du nach dem primärschlüssel, kriegst du exakt die reihenfolge, in der die aufnahme erfolgt ist, ohne dazu das datum auch noch eindeutig machen zu müssen (was nebenbei bemerkt dann eine weitere verletzung der normalisierung darstellen würde).

Was beim derzeitigen Status beim besten Willen nicht möglich ist.

geht wunderbar. vgl. oben.

[idea-tec]

vielleicht ist dir schon aufgefallen, dass der primärschlüssel eindeutig ist

Klar ist der Primärschlüssel eindeutig, aber NICHT der Reihenfolge des Uploads entsprechend!!! Und damit im Kontext zur zeitlichen Abfolge (siehe Systemzeiten der upgeloadeten Dateien) eines Uploads ebenfalls irrelevant (siehe nachfolgende Antwort)

[idea-tec]

Was beim derzeitigen Status beim besten Willen nicht möglich ist.

geht wunderbar. vgl. oben.

Dummgebabbel, weil geht nicht

[idea-tec]

der server gibt sie so zurück, wie sie im dateisystem vorliegen.

Lieber Andreas,
im Dateisystem liegen diese alphabetisch sortiert vor
das kann man sich ansehen auf der console, in einem ftp-programm.

selbst wenn uns der server da in der anzeige "verarscht" ist es doch so, dass create() nach dem upload durchgeführt wird und nicht innerhalb der Schleife.Getestet durch 3 Dateien (durchaus ausreichend), jeweils größer als 3MB um eine entsprechende Zeit verstreichen zu lassen.

Dadurch hatte ich bei Test 1 (ohne usleep()) folgendes Ergebnis:
- Die Systemzeit der Dateien war aufsteigend in der Reihenfolge in der ich die Dateien in das Uploadformular gelegt habe
=> 1.jpg=10:46:16
=> 2.jpg=10:46:30
=> 3.jpg=10:46:44
- Die Zeit im Feld created der Tabelle <prefix>_upl ist gleich der Systemzeit der letzten Datei und das für alle 3 Dateien
=> 1.jpg=10:46:44, 2.jpg=10:46:44, 3.jpg=10:46:44
- Die UPL-IDs waren DURCHEINADER
=> 1.jpg=1
=> 2.jpg=3
=> 3.jpg=2

Nachfolgender Test 2 (mit usleep()):
- Die Systemzeit der Dateien war aufsteigend in der Reihenfolge in der ich die Dateien in das Uploadformular gelegt habe
=> 1.jpg=10:52:30
=> 2.jpg=10:52:44
=> 3.jpg=10:52:58
- Die Zeit im Feld created der Tabelle <prefix>_upl ist nun eine aufsteigende Zeit > der Systemzeit der letzten Datei, für jede einzeln, jedoch dummerweise nicht in der Reihenfolge der Systemzeit der Dateien!!!
=> 1.jpg=10:52:59
=> 2.jpg=10:53:02
=> 3.jpg=10:53:01
- Die UPL-IDs waren DURCHEINADER
=> 1.jpg=1
=> 2.jpg=3
=> 3.jpg=2

So ... das sagt uns, dass sync() auf keinen Fall so auf die Dateien zugreift wie diese vorliegen, denn dann müssten die Zeiten in der DB passen!!!

[kummer]

im Dateisystem liegen diese alphabetisch sortiert vor
das kann man sich ansehen auf der console, in einem ftp-programm.

sie liegen mit absoluter sicherheit nicht alphabetisch sortiert im dateisystem vor, weil dieses nicht so funktioniert. da wird bloss die ausgabe sortiert (mit dateiname als default). du kannst aber eine x-beliebige sortierung haben, wenn du möchtest. die anzeige hat mit der ablage nichts zu tun.

readdir() liefert die datein in der reihenfolge, wie sie vorliegen (also nicht notwendigerweise alphabetisch). scandir() macht im unterscheid dazu eine sortierung, wobei alphabetische sortierung als default festgelegt ist.

selbst wenn uns der server da in der anzeige "verarscht" ist es doch so, dass create() nach dem upload durchgeführt wird und nicht innerhalb der Schleife.Getestet durch 3 Dateien (durchaus ausreichend), jeweils größer als 3MB um eine entsprechende Zeit verstreichen zu lassen.

unbestritten richtig.

So ... das sagt uns, dass sync() auf keinen Fall so auf die Dateien zugreift wie diese vorliegen, denn dann müssten die Zeiten in der DB passen!!!

dieser schluss ist dann wieder falsch. aber das ist zunächst unerheblich. ein upload kann sowohl durch http erfolgen als auch über ftp. im zweiten fall wird kein prozess angeworfen, der die übertragung in die db vornehmen könnte. deshalb wird das dateisystem in dem moment gescanned, wenn die anzeige erfolgen soll. das ist nicht prinzipiell schlecht, da auf diese weise auch dateien erfasst werden, die per ftp hochgeladen worden oder gelöscht worden sind. eine sortierung beim einlesen der daten bringt dann keine vorteile (auch keine relevanten nachteile freilich, von einem marginalen leistungsunterschied durch die sortierung einmal abgesehen, der nicht spürbar sein dürfte); aber da nur neue dateien aufgenommen werden, resultiert in der db dann doch keine korrelation zwischen datum und dateiname. die verwendung der dateisystemzeit wäre hier in der tat eine möglichkeit. du stellst ja einen gap zwischen fs-zeit und db-zeit fest. der ist klar. zuerst der upload, dann weiterleitung auf übersicht, dann sannen und einfügen. die zeit dazwischen ist der feststellbare unterscheid und deshalb haben dann auch alle die gleiche uhrzeit. hier könnte man einfach die dateisystemzeit auslesen und verwenden. allerdings muss diese nicht zwangsläufig mit derjenigen übereinstimmen, die in mysql verwendet wird. aber das dürfte keine massgebliche rolle spielen. auf jeden fall würde dann die zeitliche reihenfolge mit derjenigen übereinstimmen, die du im upload festgelegt hast. das wäre insbesondere dann günstig, wenn der upload mit ftp erfolgt ist. dort kann der zeitliche unterschied ja reichlich gross werden, da die aufnahme in die db erst dann erfolgt, wenn jemand sich die übersicht des entsprechenden verzeichnisses anzeigen lässt.

[kummer]

vielleicht ist dir schon aufgefallen, dass der primärschlüssel eindeutig ist

Klar ist der Primärschlüssel eindeutig, aber NICHT der Reihenfolge des Uploads entsprechend!!! Und damit im Kontext zur zeitlichen Abfolge (siehe Systemzeiten der upgeloadeten Dateien) eines Uploads ebenfalls irrelevant (siehe nachfolgende Antwort)

das hat auch niemand behauptet. ich gehe immer davon aus, dass du - wie du ja immer betonst - das system besser kennst als jemand sonst. dann solltest du längst beobachtet haben, dass die übertragung in die db erfolgt, sobald das verzeichnis angezeigt wird. was den vorteil hat, dass ein upload eben auch mit ftp erfolgen kann. wie gesagt kann man einfach die fs-zeit verwenden. warum auch nicht?

à propos dummgebrabel: du teilst immer mit der ganz grossen kelle aus. das ist zwar unfreundlich, kann man aber durchaus machen - ausreichend sachverstand vorausgesetzt. du bezeichnest immer alle als dummköpfe und hast selber nicht den geringsten sachverstand. das ist dann nicht mehr nur unfreundlich, sondern schlicht dumm. wenn die zeit irgendwann kommt und du tatsächlich weisst, was du tust, wenn du dich hinsetzt um zu programmieren, dann kannst du andere meinetwegen bezeichnen wie du magst. das ist dann immer noch unfreundlich, aber immerhin nicht so beschämend dämlich.

[idea-tec]

dass ein upload eben auch mit ftp erfolgen kann

ftp ist hiervon doch (zunächst) unberührt und vollkommen uninteressant, da kaum ein redakteur seine dateien per ftp hochlädt, sondern diese das in der dateiverwaltung vornehmen.
du selbst hast weiter vorne geschrieben, dass das mit der zeit ein Problem sei, wenn mehrere Redakteure hochladen, etc.. was im übrigen irrelevant ist, da diese in der regel nicht in die gleichen ordner uploaden

wie gesagt kann man einfach die fs-zeit verwenden. warum auch nicht?

Wenn diese Zeitangabe verwendet würde, wäre das ja super!!!
wird sie aber nicht, sondern es wird die letzte Zeit der zuletzt hochgeladenen datei verwendet, welche auch nur zufällig gleich ist, weil die funktion für den db-eintrag umgehend ausgeführt wird. Was dann aber noch immer nicht das Problem löst, dass die Dateien nicht in der Reihenfolge des Uploads in die DB geschrieben werden, was einem aufmerksamen Redakteur dann je nach Konfiguration der Sortierung des verwendeten Moduls in der Ausgabe auffallen wird ich meine es ist mir aufgefallen, und ich bin ja ein WebDepp

Nachtrag: Achja ... würde diese Zeit verwendet, wäre es auch bei FTP-Upload unerheblich und eine entsprechende Durchgängigkeit und Reihenfolge wäre gewährleistet. Ist mir gerade mal so aufgefallen

[McHubi]

idea-tec: - Wieso erhalten 2-10 Dateien bei einem Multi-Upload die gleiche Uhrzeit?

Nun, das "Problem" hast Du aber nicht nur bei einem upload in Contenido sondern auch per FTP. Du interpretierst den die Anordnung der Durchsuchen-Felder im Upload-Reiter von Contenido evtl. falsch. Du setzt damit keinerlei Prioriäten - was Du aber vermutest. Wenn Du per FTP Dateien hochlädst, bekommen die auch alle das gleiche Datum und die gleiche Uhrzeit. Eben weil alle gleichzeitig in die Abarbeitungsschlange einsortiert werden da für alle gleichzeitig das "Go" zum Upload erfolgt.

idea-tec: ftp ist hiervon doch (zunächst) unberührt und vollkommen uninteressant, da kaum ein redakteur seine dateien per ftp hochlädt,

Was ist, wenn die Bildergalerie Deines Redakteurs nach der Dateizeit sortiert werden soll aber aus 300 Bildern des letzten Korsika-Urlaubs besteht? Willst Du tatsächlich alle Bilder über Contenido hochladen nur weil dann durch ein Workaround jede Datei eine "eigene" Zeit bekommt? Da ist doch dann eher der Griff zum FTP die Folge,oder? Und hier hängt's dann wieder am Ausgangsproblem. Wie würdest Du denn im FTP die Priorität setzen wollen?

Was ist denn so schlimm daran, wenn 5 Dateien mit gleicher Zeit bei einer Sortierung nach Dateizeit in einem Block hintereinander angezeigt werden? Macht sich denn Dein Redakteur beim Multi-Upload überhaupt darüber Gedanken welche Datei jetzt oben rein kommt und welche weiter unten?

[kummer]

du selbst hast weiter vorne geschrieben, dass das mit der zeit ein Problem sei, wenn mehrere Redakteure hochladen, etc.. was im übrigen irrelevant ist, da diese in der regel nicht in die gleichen ordner uploaden

das auch kein ratespiel und sollte auch kein hoffen und bangen sein. richtig programmiert mit dem richtigen konzept stellt gleichzeitigkeit kein problem dar. gleichzeitigkeit ist nur vermeidbar, wenn man die möglichkeiten des systems beschneidet. bei null gewinn auf der anderen seite. es wäre dann ein problem, wenn du den zeitstempel auf unique stellen würdest und dich darauf verlassen können müsstest, dass eindeutigkeit vorliegt.

wie gesagt kann man einfach die fs-zeit verwenden. warum auch nicht?

Wenn diese Zeitangabe verwendet würde, wäre das ja super!!!
wird sie aber nicht, sondern es wird die letzte Zeit der zuletzt hochgeladenen datei verwendet, welche auch nur zufällig gleich ist, weil die funktion für den db-eintrag umgehend ausgeführt wird.

tja, dann pass das doch so an. es ist dir unbenommen. unklar freilich, ob es dann eingang in die version 4.8.14 oder höher finden wird. das hängt ja mehr vom zufall ab, als von der sache.

Was dann aber noch immer nicht das Problem löst, dass die Dateien nicht in der Reihenfolge des Uploads in die DB geschrieben werden, was einem aufmerksamen Redakteur dann je nach Konfiguration der Sortierung des verwendeten Moduls in der Ausgabe auffallen wird ich meine es ist mir aufgefallen, und ich bin ja ein WebDepp

wenn die fs-zeit verwendet wird, dürfte die reihenfolge dann stimmen. die spielt zwar nach wie vor keine rolle. wozu auch? trotzdem dürfte sie so sein, wie du es erwartest. ich würde es für eher ungünstig halten, wenn ich die reihenfolge in einer galerie durch meinen upload bestimmen müsste. bei einer änderung müsste ich die dateien dann löschen und in einer neuen reihenfolge hochladen. das würde ich jetzt nicht wollen. aber wenn deine kunden damit kein problem haben auch gut.

[idea-tec]

Andreas, bist du so doof oder tust du nur so um Links zu spammen? Allerdings wäre ja auch denkbar, dass du gedanklich dicht machst, wenn du idea-tec liest

wenn die fs-zeit verwendet wird, dürfte die reihenfolge dann stimmen. die spielt zwar nach wie vor keine rolle. wozu auch? trotzdem dürfte sie so sein, wie du es erwartest. ich würde es für eher ungünstig halten, wenn ich die reihenfolge in einer galerie durch meinen upload bestimmen müsste. bei einer änderung müsste ich die dateien dann löschen und in einer neuen reihenfolge hochladen. das würde ich jetzt nicht wollen. aber wenn deine kunden damit kein problem haben auch gut.

Weil die zweite Variante für eine saubere Reihenfolge im Sinne des Redakteurs (Reihenfolge der Auswahl im Upload) auch OHNE zeit nciht stimmt, weil die upl_id nicht passend zur reihenfolge eingetragen wird.

Tatsache ist: Contenido ist an der Stelle im Core nicht sauber umgesetzt => denn man kann nicht einmal die upl_id hernehmen!!!

Ergo: würde wenigstens eines der beiden passen: Uhrzeit oder upl_id zur Reihenfolge des Uploads, dann wäre es annehmbar. So würde ich das als Bug bezeichnen.

[kummer]

Nun, das "Problem" hast Du aber nicht nur bei einem upload in Contenido sondern auch per FTP. Du interpretierst den die Anordnung der Durchsuchen-Felder im Upload-Reiter von Contenido evtl. falsch. Du setzt damit keinerlei Prioriäten - was Du aber vermutest. Wenn Du per FTP Dateien hochlädst, bekommen die auch alle das gleiche Datum und die gleiche Uhrzeit. Eben weil alle gleichzeitig in die Abarbeitungsschlange einsortiert werden da für alle gleichzeitig das "Go" zum Upload erfolgt.

dann verwendest du allerdings ein sonderbares ftp-instrument oder einen selbstgestrickten ftp-server. in der normal-welt kriegt jede datei als timestamp den zeitpunkt, in dem es im dateisystem angelegt worden ist. unabhängig davon, ob das in einem rutsch hochgeladen wird oder nicht. erst contenido macht dann daraus einen singulären zeitpunkt. das ist zwar nicht wirklich ein gravierendes problem, aber sachlich durchaus falsch. insofern wäre es mindestens nicht schlecht, wenn man dazu die dateisystemzeit verwenden würde; die stimmt dann auch beim upload mit ftp (wie auch karsten beim zweiten mal lesen meines beitrags festgestellt hat).

das problem ist also nicht wirklich gross. da gibt's vermutlich andere bugs, die bedeutender sind. aber es ist schon zutreffend, dass es nicht der erwartung entspricht, die man in diesem zusammenhang richtigerweise haben muss.