nicht angemeldet
Wie mit Webapplication große Dateien verwalten?
Hallo,
ich überlege mir gerade, ob und wie es möglich ist, große Dateien mit einer webbasierten Anwendung zu verwalten.
Angenommen, die Datei ist 200 MB groß. Wie ist es dann am geschicktesten (ressourcenschonendsten), eine Upload-Möglichkeit für diese Datei zu realisieren und auch eine Downloadmöglichkeit?
Der Download soll auch über die Applikation erfolgen, da der Datenpool wohl außerhalb von htdocs liegen wird.
Irgendwelche Ideen?
Welche Umgebung (PHP/Perl/JSP/...) eignet sich hierzu am besten?
Liebe Grüße
Sebastian
-
Moin!
Angenommen, die Datei ist 200 MB groß.
Ne Menge Holz. LAN oder WAN?
Du willst die Datei hochladen, runterladen, ändern, hochladen...
Wie ist es dann am geschicktesten (ressourcenschonendsten), eine Upload-Möglichkeit für diese Datei zu realisieren und auch eine Downloadmöglichkeit?
Betriebssystem? Gibt es rsync für Windows?--- es gibt aber auch cwRsync
Beides dient dazu im Falle des Falles nicht ganze Dateien, sondern nur die Änderungen zu übertragen.
Der Download soll auch über die Applikation erfolgen, da der Datenpool wohl außerhalb von htdocs liegen wird.
"Application"- Anwendung? Es soll also eine Anwendung geschrieben werden. Die kann ja externe Anwendungen benutzen. In dem Fall ist die Programmiersprache egal.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
Hi
"Application"- Anwendung? Es soll also eine Anwendung geschrieben werden. Die kann ja externe Anwendungen benutzen. In dem Fall ist die Programmiersprache egal.
Als Protokoll würde sich FTP gradezu anbieten.
Die daraus resultierende Application wäre dann wohl ein FTP-Client.so long
Ole
(8-)>--
Trotz Equalizer und Compressor, der Sound wird matschig unn nett
bässer!-
Moin!
Hi
"Application"- Anwendung? Es soll also eine Anwendung geschrieben werden. Die kann ja externe Anwendungen benutzen. In dem Fall ist die Programmiersprache egal.
Als Protokoll würde sich FTP gradezu anbieten.
Kommt drauf an. FTP ist ein "Klartextprotokoll". Soll denn die Datei unverschlüsselt über das Netz gehen?
Der Op möge seine Anforderungen genauer spezifieren.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
Hi
Kommt drauf an. FTP ist ein "Klartextprotokoll". Soll denn die Datei unverschlüsselt über das Netz gehen?
Gibt ja auch noch sFTP.
Der Op möge seine Anforderungen genauer spezifieren.
Genau :)
so long
Ole
(8-)>--
Trotz Equalizer und Compressor, der Sound wird matschig unn nett
bässer! -
Hi!
Kommt drauf an. FTP ist ein "Klartextprotokoll". Soll denn die Datei unverschlüsselt über das Netz gehen?
Das ist erstmal egal, da es sich hierbei erstmal nur um ein privates Testprojekt handelt. Darüberhinaus können ja beispielsweise der Webserver (für die Webapplication) und der FTP-Server auf einer Maschine laufen, was Verschlüsselung unnötig macht.
Außerdem kann man FTP immer noch durch whatever ersetzen, wenn man das Prinzip kapiert hat. Sprich: Wie kann eine auf dem Webserver laufende Applikation in PHP/Perl/JSP/whatever effizient mit großen Dateien bei Up/Downloads umgehen?Liebe Grüße
Sebastian-
Hallo
Darüberhinaus können ja beispielsweise der Webserver (für die Webapplication) und der FTP-Server auf einer Maschine laufen...
bisher ist immer noch unklar warum es unbedingt diese Webapplication geben muss. Ein FTP Server + Client dazu sind ratz fatz installiert und sie bieten eine hervorragende Umgebung für Upload/Download bzw. Verwaltung von Dateien weitestgehend unabhängig von der Dateigröße.
Außerdem kann man FTP immer noch durch whatever ersetzen, wenn man das Prinzip kapiert hat.
Um das "Prinzip" zu kapieren solltest du dich vielleicht erstmal mit dem FTP und HTTP Protokoll genauer ausseinandersetzen und vor allem die Unterschiede und die Einsatzgebiete ausarbeiten.
Sprich: Wie kann eine auf dem Webserver laufende Applikation in PHP/Perl/JSP/whatever effizient mit großen Dateien bei Up/Downloads umgehen?
Effizient gar nicht. Egal welche Programmiersprache, Datei Uploads per HTTP sind eine häßliche Sache.
Gruß,
Cruz-
Hi,
Darüberhinaus können ja beispielsweise der Webserver (für die Webapplication) und der FTP-Server auf einer Maschine laufen...
bisher ist immer noch unklar warum es unbedingt diese Webapplication geben muss. Ein FTP Server + Client dazu sind ratz fatz installiert und sie bieten eine hervorragende Umgebung für Upload/Download bzw. Verwaltung von Dateien weitestgehend unabhängig von der Dateigröße.
Eine Webapplikation bietet mir eben mehr Möglichkeiten. Damit kann ich beispielsweise zu jeder Datei eine Notiz hinterlegen, ein Dokument nach PDF konvertieren oder auch einfach nur ein schnuckeliges Interface haben ;-)
Um das "Prinzip" zu kapieren solltest du dich vielleicht erstmal mit dem FTP und HTTP Protokoll genauer ausseinandersetzen und vor allem die Unterschiede und die Einsatzgebiete ausarbeiten.
Ohne die RFCs zu beiden komplett gelesen zu haben, wage ich zu behaupten, den unterschiedlichen Einsatzzweck zu kennen ;-)
Ging es mir wirklich nur um das Kopieren einer Datei von A nach B und zurück, hätte ich ohnehin ein Netzwerkdateisystem (NFS,CIFS,...) vorgezogen.Effizient gar nicht. Egal welche Programmiersprache, Datei Uploads per HTTP sind eine häßliche Sache.
Weil ein Upload von X MB X+Y MB Speicherlast verursacht?
Auf der anderen Seite existiert ja z.B. WebDAV, und das ist ja letztlich nichts anderes als ein aufgebohrtes HTTP. Also es muss ja bereits Leute gegeben haben, die vor dem gleichen Problem standen: Eine per Browser bedienbare Webapplication zur Verwaltung von Dateien ;-) - Nur würde ich eben ungern die Dateigröße auf 2MB oder whatever beschränken, sonst hab ich da nichts von :-)
Liebe Grüße
Sebastian-
Moin!
Da Du, egal von welcher Programmiersprache aus, auch Betriebssystemaufrufe tätigen kannst empfehle Ich Dir, Dich mal mit rsync zu beschäftigen. Dieses überträgt nur die Differenz zwischen den Dateien, Du sparst also erheblich Datenverkehr. Allerdings müsste hier jeder Datenverkehr seitens des Webservers angestoßen werden, weil Clientseitig wird jeder brauchbare Browser ein solche Systemaufrufe verhindern. Dir bliebe also nur das HTTP-Protokoll. Du müsstest auf dem Client also etwas haben, was auf rsync-Anforderungen reagiert. Das kann zum Beispiel ein ssh-demon sein.
Deinen bisherigen Ausführungen entnehme ich, dass Du eine Datei auf einem (Web-) Server liegen hast, diese zum Client transportieren willst, dort verarbeiten und zurückspielen willst.
Die angesprochenen Beschränkungen für PHP- Speicherverbrauch, maximale Uploadgröße, maximale Menge der Post-Daten, Laufzeitbeschränkungen lassen sich auch konfigurieren. Du bist also an keine Grenzen gebunden, wenn Du den Server selbst konfigurieren oder die gesetzten Einstellungen überschreiben mittels .htaccess überschreiben kannst.
Daneben existiert eventuell noch das Problem der Mehrbenutzerfähigkeit: Hier erwarte ich ggf. größere Probleme bei jeglicher Benutzung verbindungsloser Protokolle. Aber dazu hast Du noch gar nichts geschrieben.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
Die angesprochenen Beschränkungen für PHP- Speicherverbrauch,
Wie sieht denn dieser Speicherverbrauch aus? Angenommen, ich konfiguriere eine maxuploadsize von 1 G. Wie hoch ist der Speicherverbrauch bei sagen wir einer Dateigröße von 100 M?
Daneben existiert eventuell noch das Problem der Mehrbenutzerfähigkeit: Hier erwarte ich ggf. größere Probleme bei jeglicher Benutzung verbindungsloser Protokolle. Aber dazu hast Du noch gar nichts geschrieben.
Mal langsam. Eins nach dem anderen ;-)
Eventuell werde ich mich dazu durchringen, die Weboberfläche nur als Notfall-Lösung zu schreiben und einen echten nativen Client für den Zugriff zu benutzen.
Liebe Grüße
Sebastian-
Moin!
Daneben existiert eventuell noch das Problem der Mehrbenutzerfähigkeit: Hier erwarte ich ggf. größere Probleme bei jeglicher Benutzung verbindungsloser Protokolle. Aber dazu hast Du noch gar nichts geschrieben.
Mal langsam. Eins nach dem anderen ;-)
Nein, eben nicht. Du entwickelst in die völlig falsche Richtung falls Du Techniken einsetzt, die einen Mehrbenutzerbetrieb nicht ermöglichen. Sowas muss _vorher_ schon klar sein. Sonst wird es Stuss.
Beispiel? Microsoft Access und dessen tolle Mehrbenutzerfähigkeiten...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
-
-
-
Eine Webapplikation bietet mir eben mehr Möglichkeiten. Damit kann ich beispielsweise zu jeder Datei eine Notiz hinterlegen, ein Dokument nach PDF konvertieren oder auch einfach nur ein schnuckeliges Interface haben ;-)
Aha, da kommen wir der Sache schon näher. Du möchtest also eine webbasierte Dokumentenverwaltung haben mit intelligenten Funktionen. Ja das ist an und für sich ein ehrbahres Vorhaben und in einer ausgereiften Form sicherlich auch nützlich. Wobei es immer noch zu erwägen gilt, warum die Oberfläche unbedingt Web sein muss.
Effizient gar nicht. Egal welche Programmiersprache, Datei Uploads per HTTP sind eine häßliche Sache.
Weil ein Upload von X MB X+Y MB Speicherlast verursacht?
Nein das nicht. Ich weiss nicht was "Speicherlast" heisst, aber Upload Geschwindigkeit und verbrauchter Festplattenplatz ist bei allen Protokollen vergleichbar. Kompression ist das einzig mir bekannte Verfahren, womit sich diese beiden Aspekte optimieren lassen.
HTTP ist in erster Linie deswegen schlecht für den Upload, weil er die Vorteile von anderen Protokollen nicht mitbringt. Was ist z.B. wenn die Übertragung bei 99% abbricht? Dann kannst du dich nur ärgern und von vorne anfangen. Schau du dir mal an was z.B. rsync so alles kann... Außerdem, wenn du bei einer HTTP Übertragung "unter die Haube" schaust und siehst, dass eine Datei in Klartext umgewandelt und mit HTTP spezifischen Kram "angereichert" wird dann stehen dir die Haare zu Berge. Dann ist da auch immer noch ein Webserver dazwischen, der seine eigenen Zicken macht, mit denen du dich ausseinandersetzen musst. Vielleicht wird z.B. bei der default Einstellung eine Verbindung nach einer gewissen Zeit automatisch gekappt, was sich ganz schlecht macht bei einer Übertragung von mehreren 100 MBs. Funktionieren tut das insgesamt schon, aber es wäre immer meine letzte Wahl.
Und daher meine Ablehnung gegen die Weboberfläche. Hast du dich nämlich auf eine Weboberfläche festgelegt, dann sind damit deine Hände automatisch gebunden. Entweder du nimmst ein gescheihtes Verfahren für die Datenübertragung, aber dann hast du die Unbequemlichkeit neben der Weboberfläche einen zweiten Weg für die Übertragung irgendwie unterzubringen. Nimmst du eine sauber integrierte HTTP Übertragung, dann hast du nur so ein sch**** Protokoll.
Und wenn du dich aus dem LAN raus ins Internet bewegst, dann kannst du einen Upload von über 100 MB vergessen. Das ist total unbrauchbar.
Gruß,
Cruz
-
-
-
-
-
-
Hi,
danke für alle Antworten!
Angenommen, die Datei ist 200 MB groß.
Ne Menge Holz. LAN oder WAN?Erstmal LAN. Mir ist durchaus bewusst, dass das viel ist ;-)
Der Download soll auch über die Applikation erfolgen, da der Datenpool wohl außerhalb von htdocs liegen wird.
"Application"- Anwendung? Es soll also eine Anwendung geschrieben werden. Die kann ja externe Anwendungen benutzen. In dem Fall ist die Programmiersprache egal.Application = Die Webanwendung, die über Browser zu bedienen wäre. Natürlich kann die andere Dinge wie FTP- WebDAV- oder whatever-Server benutzen. Die Frage ist nur, wie kriege ich innerhalb der WebApplication (d.h. innerhalb von PHP/Perl/JSP/whatever) eine möglichst schöne Routine implementiert, die ohne großen Ressourcenverbrauch die Datei auf den FTP-Server schaufelt bzw. von dort wieder runterzieht, um sie dem User anzubieten?
Liebe Grüße
Sebastian
-
-
Hi,
ich überlege mir gerade, ob und wie es möglich ist, große Dateien mit einer webbasierten Anwendung zu verwalten.
Ja, und theoretisch genauso wie mit kleinen Dateien.
Angenommen, die Datei ist 200 MB groß. Wie ist es dann am geschicktesten (ressourcenschonendsten), eine Upload-Möglichkeit für diese Datei zu realisieren und auch eine Downloadmöglichkeit?
Welche Ressourcen sollen denn geschont werden?
Der Download soll auch über die Applikation erfolgen, da der Datenpool wohl außerhalb von htdocs liegen wird.
Wo der Speicherort liegt ist normalerweise egal, der kann auch in Australien liegen, es muss nur ein Weg dahin bekannt sein.
Irgendwelche Ideen?
Viele und auch wieder keine, denn Du rueckst ja trotz Aufforderung nicht mit den noetigen Details raus.
Mit einem 100 MBit Netz dauert so ein Vorgang ca 20 Sekunden wenn er haendisch angestossen wird und im Netz grad' ueberhaupt nix los ist. Das ist gerade mal lang genug eine tiefen Schluck aus dem Kaffepott zu nehmen, aufzustoehnen als ob es die Muehe tatsaechlich Wert waere und -- Zack: schon ist die Datei da bzw weg. Alternativ geht auch ein wenig Nasebohren, ist eine angenehm meditative Betaetigung. Es ist nur darauf zu achten, das man vorher keine Chilis geschnibbelt hat.
Die einzige Moeglichkeit hier irgendetwas zu sparen ist es, nicht den ganzen Datensatz zu uebertragen. Der Vorschlag wurde aber auch schon gemacht. Warum hat der nicht Deinen Beifall gefunden?
Welche Umgebung (PHP/Perl/JSP/...) eignet sich hierzu am besten?
Wozu eine Programmiersprache, moechtest Du die Datei auf dem Server noch bearbeiten?
Diese Posting verdankst Du meiner Prostata, sie bittet auf diesem Wege um Nachsicht.
so short
Christoph Zurnieden
-
Hi,
Angenommen, die Datei ist 200 MB groß. Wie ist es dann am geschicktesten (ressourcenschonendsten), eine Upload-Möglichkeit für diese Datei zu realisieren und auch eine Downloadmöglichkeit?
Welche Ressourcen sollen denn geschont werden?
Beispielsweise der Arbeitsspeicher, da ich nicht möchte, dass PHP beim Hoch-/Herunterladen einer 200 MB 200+X MB Speicher frisst.
Mit einem 100 MBit Netz dauert so ein Vorgang ca 20 Sekunden wenn er haendisch angestossen wird und im Netz grad' ueberhaupt nix los ist. Das ist gerade mal lang genug eine tiefen Schluck aus dem Kaffepott zu nehmen, aufzustoehnen als ob es die Muehe tatsaechlich Wert waere und -- Zack: schon ist die Datei da bzw weg. Alternativ geht auch ein wenig Nasebohren, ist eine angenehm meditative Betaetigung. Es ist nur darauf zu achten, das man vorher keine Chilis geschnibbelt hat.
Es geht nicht um die Leitung, sondern um die Applikation selber.
Die einzige Moeglichkeit hier irgendetwas zu sparen ist es, nicht den ganzen Datensatz zu uebertragen. Der Vorschlag wurde aber auch schon gemacht. Warum hat der nicht Deinen Beifall gefunden?
So etwas wie RSync? Das ist ja ganz nett, aber ich möchte ja eine mit dem Browser bedienbare Applikation schreiben, mit der so etwas möglich ist.
Welche Umgebung (PHP/Perl/JSP/...) eignet sich hierzu am besten?
Wozu eine Programmiersprache, moechtest Du die Datei auf dem Server noch bearbeiten?
Eventuell. Später vielleicht, jetzt erstmal nur speichern und abfragen. Also entweder ich nehme so etwas wie RSync oder ich gehe rein auf PHP/JSP/... Nehme ich so etwas wie RSync braucht PHP trotzdem diese Dateiverwaltung, es soll ja über Browser bedienbar sein.
Liebe Grüße
Sebastian-
Moin!
So etwas wie RSync? Das ist ja ganz nett, aber ich möchte ja eine mit dem Browser bedienbare Applikation schreiben, mit der so etwas möglich ist.
<?php
$strClient=$_SERVER["REMOTE_ADDR"];
$strReturn=rsync -rltuzv $strClient::verz/verz1/datei.endung;
?>Stößt serverseitig den Prozess des Abholens der Datei(-Änderungen) an. Du brauchts jetzt nur noch einen Rückweg vom Deinem Webserver zum 'Web-Client'. Aber den kann rsync auch.
-> "Note that rsync must be installed on both the source and destination machines." <-
Mehr Informationen bekommst Du mit:
- man rsync (Auf UNIX/Linux)
- info rsync (Auf UNIX/Linux)
Oder bei:
http://www.tux.org/~tbr/rsync/rsynchowto.html
Auf deutsch
http://wwwbs1.informatik.htw-dresden.de/fsys/fadmin/rsync/printm8rsync1.htmlMFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development-
Hi,
<?php
$strClient=$_SERVER["REMOTE_ADDR"];
$strReturn=rsync -rltuzv $strClient::verz/verz1/datei.endung;
?>Okay, das ist klar. Das hat mit Rsync nichts zu tun, es würde auch ein readfile($filename); reichen, oder ein Download von einem FTP-Server oder was auch immer.
Ich denke in beiden Fällen gibt PHP einfach das aus, was es selber empfängt. Für den verbrauchten RAM eigentlich ideal.
Ob Rsync, irgendeine dazu missbrauchte BackUp-Suite oder was auch sonst immer, spielt imho dabei keine entscheidene Rolle, wie gesagt, es geht mir erstmal um's Prinzip.Schwieriger wird der Upload. Wie kriegt man es möglichst intelligent hin, dass PHP eine hochgeladene Datei zum Rsync/FTP/NFS/..../-Server oder einfach auf dem FS speichert? Würde sowas reichen wie
system("/usr/local/bin/programmzumspeichern $_FILES['dateifeld']['tmp_name']");
Liebe Grüße
Sebastian-
Moin!
rsync speichert auf dem Dateisystem... in $strReturn ständen die Rückgaben von rsync, nicht das File.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
-
-
Hi,
Welche Ressourcen sollen denn geschont werden?
Beispielsweise der Arbeitsspeicher, da ich nicht möchte, dass PHP beim Hoch-/Herunterladen einer 200 MB 200+X MB Speicher frisst.
Ich weiss nicht wieviel PHP da verbraet, aber das laesst sich ja leicht probieren. Vielleicht laesst sich die Datei ja auch direkt "durchleiten".
Aber das ist nicht direkt Dein Problem, wenn Du das HTTP benutzt. Hauptsaechlich duerften Dir da die Browser Aerger machen: ein Dateiupload kann nicht weiter reguliert werden; auf die Implementation hast Du keinen Einfluss.All die Diskussion hier setzt aber, da Du immer noch keine Details geliefert hast, stillschweigend voraus, das die Datei nur am Stueck benutzt werden kann und inkompressibel (z.B. verschluesselt o.ae.) ist.
So etwas wie RSync? Das ist ja ganz nett, aber ich möchte ja eine mit dem Browser bedienbare Applikation schreiben, mit der so etwas möglich ist.
Was ist das fuer ein Datensatz, den Du im Browser bearbeiten kannst, aber nur komplett und der 200 MiBs gross ist?
Bist Du Dir sicher, das Du Dein Problem korrekt geschildert hast?
Wozu eine Programmiersprache, moechtest Du die Datei auf dem Server noch bearbeiten?
Eventuell. Später vielleicht, jetzt erstmal nur speichern und abfragen.
Nein, so funktioniert das nicht, das sind zwei veschiedenfarbene Socken, das ist kein Paar.
Wenn Du vorhast das spaeter zu bearbeiten, dann trage von Anfang an dafuer Sorge, ansonsten ist das hinterher mehr Arbeit als ein kompletter Neuschrieb.
Genauso mit der von Dir weggeschobenen Multiusereigenschaft: wenn Du nicht von Anfang an dafuer Sorge traegst hast Du hinterher mehr Arbeit als den ganzen Schisselamaeng *from scratch* neu zu pinseln.Also entweder ich nehme so etwas wie RSync oder ich gehe rein auf PHP/JSP/... Nehme ich so etwas wie RSync braucht PHP trotzdem diese Dateiverwaltung, es soll ja über Browser bedienbar sein.
Der Browser stellt bei 'rsync' nur eine Art "Fernbedienung" dar und PHP macht nichts anderes als den Vorgang anzuschmeissen.
Problem dabei:- Du hast zwei verschiedene Protokolle statt nur einem
- beide laufen unabhaengig voneinander, wenn 'rsync' abnippelt wartet PHP vergeblich.
Insbesondere der erste Punkt verursacht eine Komplexitaet, der die Implementierung der noetigen Sicherheitmassnahmen zu einer heiklen Angelegenheit macht; falls die Verschluesselung nicht eh schon auf IP-Ebene erfolgt (empfohlen), was einiges, wenn auch leider nicht alles vereinfacht.
Aber wie gesagt: da Du nicht mit den noetigen Details rausrueckst, bleibt jeder Rat blosse Vemutung und Schuss in's Blaue.
so short
Christoph Zurnieden
-
Hi,
Was ist das fuer ein Datensatz, den Du im Browser bearbeiten kannst, aber nur komplett und der 200 MiBs gross ist?
Irgendwas. Beispielsweise irgendeine Videodatei, ein ZIP-Archiv oder sonstwas. Es soll ja nur mit der Webapplication gespeichert und von dort wieder abgerufen werden. Mehr nicht.
Der Browser stellt bei 'rsync' nur eine Art "Fernbedienung" dar und PHP macht nichts anderes als den Vorgang anzuschmeissen.
Eben. Aber dazu muss PHP beispielsweise auch wissen, was da zum Server geschoben werden soll. Bzw. was geholt werden muss.
Ob das PHP Script das dann irgendwo im Filesystem speichert oder die Informationen nutzt, um einen Vorgang anzuschmeißen ist prinzipiell doch das gleiche oder liege ich da völlig falsch?Liebe grüße
Sebastian-
Hi,
Was ist das fuer ein Datensatz, den Du im Browser bearbeiten kannst, aber nur komplett und der 200 MiBs gross ist?
Irgendwas. Beispielsweise irgendeine Videodatei, ein ZIP-Archiv oder sonstwas. Es soll ja nur mit der Webapplication gespeichert und von dort wieder abgerufen werden. Mehr nicht.
Ja, das habe ich schon befuerchtet, wollt' nur noch mal fragen.
Der Browser stellt bei 'rsync' nur eine Art "Fernbedienung" dar und PHP macht nichts anderes als den Vorgang anzuschmeissen.
Eben. Aber dazu muss PHP beispielsweise auch wissen, was da zum Server geschoben werden soll. Bzw. was geholt werden muss.
Nein, nur 'rsync' muss das wissen. Wenn Du moechtest kannst Du ihm das per Webbrowser->Webserver sagen.
Ob das PHP Script das dann irgendwo im Filesystem speichert oder die Informationen nutzt, um einen Vorgang anzuschmeißen ist prinzipiell doch das gleiche oder liege ich da völlig falsch?
Im Endeffekt ja, aber auch nur da.
'rsync' ist fuer solche Zwecke konzipiert, die Dateiuploadmoeglichkeit des Browsers ist es nicht. Auch ist PHP nicht dafuer gebaut mal eben 200MiB entgegenzunehmen und a.a.O. zu speichern. Beides zusammen koennte jedoch Sinn machen. Ob das tatsaechlich der Fall ist: dafuer fehlen zwar wieder die Informationen, aber mit den mageren, die Du zur Verfuegung stellst wuerde ich hier einen Sinn verneinen.so short
Christoph Zurnieden
-
-
-