mikrocontroller.net

Forum: PC Hard- und Software Speichern einer großen Anzahl von Dateien


Autor: Tek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

wir haben ein Prüfsystem das Bilddateien generiert. Zur 
Rückvervolgbarkeit und Diagnose des Systems werden die Bilder 
gespeichert. Pro Tag fallen so ca 40000 Bilder a 200kb an.

Im Moment werden die Files in einer Ordnerstruktur Jahr/Monat/Tag 
abgelegt, das handling der Files ist aber aufgrund der großen Menge 
problematisch. (Beim kopieren von Bildern aus 2 Tagen von einem 
Netzlaufwerk auf eine USB Platte wird 8h als geschätzte Zeit angezeigt)

Auf die einzelnen Bilder sollte ohne größeren Aufwand zugegriffen werden 
können daher halte ich ein archivieren in zb. Zip Dateien für keine gute 
Alternative.

Am liebsten wäre mir eine Art Datenbank auf die ich dann mit einem 
selbst erstellten Tool zugreifen und Bilder hinzufügen und suchen kann. 
Vom abspeichern der Bilder als BLOB in einer SQL Datenbank wird einem 
aber eigentlich bei so großen Mengen eher abgeraten.

Kennt jemand eine Möglichkeit wie man so etwas am besten angeht?

Autor: jois3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi TeK,

wie man so etwas am besten angeht, hängt noch von einer Reihe weiterer 
Gegebenheiten ab.
Erstmal zum Bildformat: Ich vermute mal .jpg (.jpeg), d.h. nicht 
wirklich weiter komprimierbar. Das bedeutet, ein Zusammenfassen in 
zip-Dateien hat eher organisatorischen Charakter - aber genau dafür 
würde ich das in Erwägung ziehen.
Kann das Aufkommen irgendwie reduziert oder aggregiert werden? D.h. gibt 
es feststellbar gleiche Bilder, bzw. welche, die bekanntermaßen als 
nicht mehr relevant markierbar sind? Reicht es, die Unterschiede 
zwischen den Bildern zu speichern (das lohnt sich nur, wenn es nur 
geringe Unterschiede gibt, und jpeg ist dann auch ein eher unglückliches 
Speicherformat)? Oder reicht es sogar, wenn z.B. per OpenCV Aussagen aus 
den Bilder extrahiert und nur diese (gut komprimierbar) gespeichert 
werden? Ist gar nur eine Prüfsumme notwendig (auch hier ist jpeg eher im 
Weg)?

40000 Dateien in einem Ordner klingt anstrengend, je nach Zugriff. Wie 
soll auf die Dateien zugegriffen werden (nach welchen Kriterien)? Wenn 
z.B. die Stunde bekannt ist/sein soll, und die Dateien einigermaßen 
gleichverteilt über den Tag anfallen, dann bringt ein Einsortieren in 
Unterordner nach Stunden schon einiges, evtl. auch noch nach Minuten, 
z.B. ein Ordner "0941" für Bilder, die (tada) um 09:41 Uhr erstellt 
wurden. Oder eben (siehe oben) eine Zip-Datei pro Minute.

Und wenn die Daten in der Menge wirklich notwendig sind, dann solltest 
Du imho die Infrastruktur dafür auch aufbohren. 8h für 8GB (40k*200kb) 
klingt nicht gerade nach USB3...
Zum Kopieren: Am besten immer per Kommandozeile (und unter Windows am 
besten per XCopy/Robocopy). Die Vorschau auf Bilder deaktivieren, 
Ansicht auf Liste, sonst kann dies einem USB-Stick einiges abverlangen.

Gruß, jois3

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde die Bilder je Tag in ein TAR Archiv legen. (z.b. durch eine 
Jobs Nachts). Dazu würde ich in Datenbank (oder Textdatei) mir einen 
Index anlegen wo steht an welchen Offset welches Image im Tar beginnt 
und wie groß das Image ist - dann hat man auch einen sehr schnellen 
zugriff auf die Images.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Tek schrieb:
> Vom abspeichern der Bilder als BLOB in einer SQL Datenbank wird einem
> aber eigentlich bei so großen Mengen eher abgeraten.

Vom Abspeichern solch großer Datenmengen ist generell abzuraten, egal 
wohin.
Nee im Ernst, die Datenbank ist sicher noch die bessere Variante. Bei 
gleicher Gesamtdatenmenge dauert das Bewegen vieler kleiner Dateien 
durch den Overhead des Öffnens/Schließens um Größenordnungen länger als 
bei einer großen Datei. Und bei euren enormen Datenmengen wird auch die 
Sicherung/Rücksicherung äußerst zeitaufwendig und in absehbarer Zeit 
unbeherrschbar. Also klarer Rat zur Datenbank, ggfs. Aufteilen in 
mehrere Datenbanken.

: Bearbeitet durch User
Autor: Der Andere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Also klarer Rat zur Datenbank,

Dann sollte man aber vieleicht mal nach NOSQL Datenbanken schauen.
Key Value oder Dokumentenzentrierten Datenbanken dürften besser auf das 
Problem passen und bessere Performance und skalierbarkeit bieten.

Gibt es vieleicht spezielle Bilddatenbanken für sowas?

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> . Und bei euren enormen Datenmengen wird auch die
> Sicherung/Rücksicherung äußerst zeitaufwendig und in absehbarer Zeit
> unbeherrschbar. Also klarer Rat zur Datenbank, ggfs. Aufteilen in
> mehrere Datenbanken.

auf keinen Fall würde ich sagen, klar eine große Datenbank klingt 
einfacher. Hat aber den großen Nachteil das man nicht einen kleinen Teil 
der Daten wiederherstellen kann. Wenn man jeden tag in ein Tar packt 
kann man tageweise Sichern und Widerherstellen. Für jeden Tag eine 
Datenbank ist unhandlich.

Auch das Sichern ist nicht wirklich einfach, weil man schlecht von der 
Datenbank Differenzen ermitteln kann im schlimmsten fall wird bei sicher 
jeden Tag die Datenbank komplett kopiert.

Wie haben auch über 50.000.000 Dateien auf einen System liegen. Nur 
kostet das dann etwas mehr als ein einfaches NAS.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000 Dateien pro Tag 
sind nicht viel.

Du solltest genauer erklären was ihr genau machen wollt. Wenn dir nur 
das kopieren auf eine USB-Festplatte zu lange dauert, musst du 
herausfinden warum es so lange dauert. 16Gb in 40000 Dateien sollte 
keine 8 Stunden dauern.

Autor: ergo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RIAK KV kann sowas z.B.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Dateimanager von Windows und Ubuntu Linux tun sich mit vielen 
Dateien sehr schwer. Sie sind langsam und neigen bei so viele Dateien 
dazu, sich spontan aufzuhängen oder auch mal Dateien auszulassen.

Der Tip mit der Kommandozeile war schon goldrichtig - bei beiden 
Betriebsystemen.

Eine Datenbank bringt Dir den Vorteil, dass sie die Dateien 
(=Datensätze) indiziert, so dass du schneller suchen kannst. Aber wonach 
willst du suchen? Vermutlich nur nach Zeitstempel, richtig? Das kannst 
du in deinem gruppierten Dateisystem genau so gut.

Bei Kopieren von Massendaten wird die Datenbank hingegen keinen 
wesentlichen Vorteil haben. Im Gegenteil, da der Kopiervorgang auch das 
Aktualisieren des Index mit sich bringt, kostet es sogar vielleicht 
sogar noch extra Zeit.

Letztendlich ist das Dateisystem selbst schon eine Datenbank - nur mit 
fest vorgegebener Struktur des Index, nämlich dem Inhaltsverzeichnis.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> Auch das Sichern ist nicht wirklich einfach, weil man schlecht von der
> Datenbank Differenzen ermitteln kann im schlimmsten fall wird bei sicher
> jeden Tag die Datenbank komplett kopiert.

Dafür wurden transaction logs erfunden.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000 Dateien pro Tag
> sind nicht viel.

Doch, das ist schon eine ganze Menge, wenn man nicht gerade in einem 
Rechenzentrum sitzt und auf hochperformante SANs speichert, sondern mit 
Technik aus dem SoHo-Bereich klarkommen muß.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tek schrieb:
> Beim kopieren von Bildern aus 2 Tagen von einem
> Netzlaufwerk auf eine USB Platte wird 8h als geschätzte Zeit angezeigt

Muss das ein Netzlaufwerk sein? Ich würde die USB-Platte an die Maschine 
anschliessen, die die Bilder speichert.

Georg

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Peter II schrieb:
>> Auch das Sichern ist nicht wirklich einfach, weil man schlecht von der
>> Datenbank Differenzen ermitteln kann im schlimmsten fall wird bei sicher
>> jeden Tag die Datenbank komplett kopiert.
>
> Dafür wurden transaction logs erfunden.

und dann willst du beim restore erst mal das Backup einspielen und dann 
noch 356 diffs dazu?

Und was ist wenn du 1 Datei aus dem Backup brauchst?

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:

> mh schrieb:
>> Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000
>> Dateien pro Tag sind nicht viel.
>
> Doch, das ist schon eine ganze Menge, wenn man nicht
> gerade in einem Rechenzentrum sitzt und auf hochperformante
> SANs speichert, sondern mit Technik aus dem SoHo-Bereich
> klarkommen muß.

Es stört aber eher die Anzahl, nicht das Datenvolumen.

8GByte (=8'000 MByte) gehen in 5 Minuten (=300s) über den
USB.

Das letzte Buch, das ich eingescannt habe, hat 600 Seiten
zu je 40MByte. Die Nachbehandlung lässt sich mühelos auf
einem 10 Jahre alten PC machen.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tek schrieb:

> Pro Tag fallen so ca 40000 Bilder a 200kb an.
>
> Kennt jemand eine Möglichkeit wie man so etwas
> am besten angeht?

Bilder viertelstundenweise als tar-Archive zusammenfassen.
Automatisiert natürlich.

Für einen Tag (=24h) gibt das 96 Dateien mit je 400
Bildern, also je tar-File ca. 80MByte.

Topmoderne graphische Filemanager (wie der Midnight
Commander:) können direkt mit tar-Archiven umgehen, d.h.
diese wie Verzeichnisse "öffnen". Der wahlfreie Zugriff
ist dadurch nicht eingeschränkt.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Doch, das ist schon eine ganze Menge, wenn man nicht gerade in einem
> Rechenzentrum sitzt und auf hochperformante SANs speichert, sondern mit
> Technik aus dem SoHo-Bereich klarkommen muß.

Man "muß" nicht mit Technik  klarkommen, die für so einen Anwendungsfall 
nicht gedacht und auch nicht sonderlich geeignet ist. Sie ist ja 
deswegen so günstig, weil sie für sowas eben nicht gebaut wurde.


Ansonsten, Dateimanager haben mit sowas Probleme, weil und wenn sie von 
Anfängern programmiert wurden (egal ob unter Linux oder bei MS). Da wird 
dann mit 50 Dateien getestet "ja geht", und das war's. Manchmal waren 
die Deppen auch bei der Entwicklung des Dateisystems, da kann der 
Dateimanager dann auch nichts mehr retten.

Siehe auch hier, da sind Shlemiels drin:
http://www.joelonsoftware.com/articles/fog0000000319.html

Alternativ auch Sortieralgorithmen, die bei 50 noch gehen, bei 40.000 
nicht mehr. Bubblesort etwa. Wer sowas in einen Dateimanager verbaut, 
gehört geschlagen.

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fileserver+ Dateinamen richtig wählen/Ondemand umbeschriften..

Eine Parallele Datenbank mit Timestamp und eindeutigem Stempel 
erstellen.. geht ja einfach da man nach Dateien Erstelldatum seit 
letztem Sync sucht.

Ich hab mal ähnliches mit CSV und einem kleinen Tool gemacht..

Die Files wurden wild in einem Ordner abgelegt, nach jedem Auftrag  hat 
man ein einfaches Batch/Java Programm geöffnet das alle Daten wie 
Auftragsnumme,Produktnummer abgefragt hat und das ganze dann passend 
verteilt, umbenannt und einsortierte.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> mh schrieb:
>> Das sind ~8GB pro Tag. Das ist nicht viel. Auch 40000 Dateien pro Tag
>> sind nicht viel.
>
> Doch, das ist schon eine ganze Menge, wenn man nicht gerade in einem
> Rechenzentrum sitzt und auf hochperformante SANs speichert, sondern mit
> Technik aus dem SoHo-Bereich klarkommen muß.

Solange man nicht versucht über eine Netzwerkverbindung auf jede Datei 
einzeln zuzugreifen, sollte das kein Problem sein.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:

> Man "muß" nicht mit Technik  klarkommen, die für so
> einen Anwendungsfall nicht gedacht und auch nicht
> sonderlich geeignet ist.

Ach so.

Niemand hat je erfolgreich einen UseNet-Server auf
PCs betrieben. Soso.

> Ansonsten, Dateimanager haben mit sowas Probleme, weil
> und wenn sie von Anfängern programmiert wurden (egal ob
> unter Linux oder bei MS).

Nein -- weil sie von Anfängern für Zwecke eingesetzt werden,
für die sie völlig ungeeignet sind.

Wozu - zum Henker! - braucht man zur sinnvollen, d.h.
automatisierten Behandlung von Dateien eine DATEIMANAGER ?

Du stellst wohl auch extra eine Hilfskraft ein, die jedes
Bild mit der Maus in den passenden Unterordner zieht?

> Manchmal waren die Deppen auch bei der Entwicklung des
> Dateisystems,

Ja... zum Beispiel die grünen Bubis, die FAT entwickelt
haben.

SCNR

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> und dann willst du beim restore erst mal das Backup einspielen und dann
> noch 356 diffs dazu?
>
> Und was ist wenn du 1 Datei aus dem Backup brauchst?

Es gibt mittlerweile Backup-Software wie VEEAM, die sogar in der Lage 
ist, einzelne Nachrichten von Exchange-Postfächern aus dem Backup 
wiederherzustellen. Sollte also nicht allzu schwer lösbar sein.
Nur mal zum Vergleich, die Dateianzahl des TE wächst pro Jahr um einen 
zweistelligen Millionenbetrag. Bei dateibasierter Speicherung würde ein 
kompletter Restore Tage dauern, wenn keine sauteure Storagetechnik 
vorhanden ist.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:
> Es stört aber eher die Anzahl, nicht das Datenvolumen.

Mein Reden:

Icke ®. schrieb:
> Bei
> gleicher Gesamtdatenmenge dauert das Bewegen vieler kleiner Dateien
> durch den Overhead des Öffnens/Schließens um Größenordnungen länger als
> bei einer großen Datei.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Solange man nicht versucht über eine Netzwerkverbindung auf jede Datei
> einzeln zuzugreifen, sollte das kein Problem sein.

Denkste, das ist sehr wohl auch dann problematisch, wenn die Dateien auf 
lokalen Laufwerken bewegt werden. Ich rede aus Erfahrung.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:
> Nur mal zum Vergleich, die Dateianzahl des TE wächst pro Jahr um einen
> zweistelligen Millionenbetrag. Bei dateibasierter Speicherung würde ein
> kompletter Restore Tage dauern, wenn keine sauteure Storagetechnik
> vorhanden ist.

nein, wie schon oben geschrieben, einfach jeden Tag in ein TAR packen 
und gut ist. Dann kann man mit Hilfe einer Index Datei sogar sofort auf 
den Inhalt zugreifen.

Backup und Restore ist dann keim Thema mehr, weil man es nur noch mit 
365 Dateien a 8GB zu tun hat.

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:

> mh schrieb:
>> Solange man nicht versucht über eine Netzwerkverbindung
>> auf jede Datei einzeln zuzugreifen, sollte das kein
>> Problem sein.
>
> Denkste, das ist sehr wohl auch dann problematisch, wenn
> die Dateien auf lokalen Laufwerken bewegt werden. Ich
> rede aus Erfahrung.

Also besteht die Lösung darin, die Dateien blockweise
zusammenzufassen. Rechenbeispiel steht weiter oben.

Ich verstehe die Diskussion nicht. (Muss ich Gott sei
Dank auch nicht...)

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Possetitjel schrieb:

> Niemand hat je erfolgreich einen UseNet-Server auf
> PCs betrieben. Soso.

Das ging ganz am Anfang, als das nicht viel mehr als Mailboxen waren. 
Gut, heute würde es wieder gehen, so wie das Usenet geworden ist.

> Nein -- weil sie von Anfängern für Zwecke eingesetzt werden,
> für die sie völlig ungeeignet sind.

Es gibt keinen Grund, wieso ein Dateimanager bei 40.000 Dateien versagt, 
wenn z.B. ls funktioniert. Außer schlampiger Programmierung mit mies 
skalierenden Algorithmen, und die sollte man auch in Dateimanagern nicht 
verwenden.

Sind übrigens dieselben Trottel, die auch sowas wie Testtools machen. 
Die funktionieren gut mit 50 Signalen. Zeichnet man damit 5000 auf, 
dauert es Stunden, bis sich alleine die Oberfläche mal aufbaut. Und dann 
stürzt sie ab.

> Wozu - zum Henker! - braucht man zur sinnvollen, d.h.
> automatisierten Behandlung von Dateien eine DATEIMANAGER ?

Dafür nicht. Um ins Verzeichnis reinzusehen dagegen schon.

> Ja... zum Beispiel die grünen Bubis, die FAT entwickelt
> haben.

Nö, FAT war schon nicht so schlecht - für Disketten. Idiotisch wurde es 
aber, als man damit angefangen hat, auf Festplatten loszugehen. 
Vermutlich veranlaßt durch inkompetente Manager, die "zack zack mal eben 
schnell los los mir doch alles egal" gedacht haben.

Autor: Tek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Antworten

jois3 schrieb:
> Erstmal zum Bildformat: Ich vermute mal .jpg (.jpeg), d.h. nicht
> wirklich weiter komprimierbar. Das bedeutet, ein Zusammenfassen in
> zip-Dateien hat eher organisatorischen Charakter - aber genau dafür
> würde ich das in Erwägung ziehen.

Die Bilder kommen aus einer Bildverarbeitung und sind unkompremiert nur 
so kann nachträglich mit anderen Parametern nochmal ausgewertet werden. 
Platztechnisch könnte da also auch noch was rausgeholt werden.

Übergeordnet gibt es eine Datenbank die mittels einer ID mit den Files 
verknüpft ist.

Der Zugriff auf die Bilder ist unterschiedlich:
Für nachträgliche Auswertungen werden z.B. alle Bilder von einer Woche 
benötigt da wären Tagesarchive unproblematisch.

Es kann aber auch sein das man mal eine Liste mit 100 Bildern verteilt 
über die letzten vier Wochen benötigt. Mit Archiven bräuchte man dann 
irgend ein Tool das die dann aus den entsprechenden Dateien extrahiert.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tek schrieb:
> Es kann aber auch sein das man mal eine Liste mit 100 Bildern verteilt
> über die letzten vier Wochen benötigt. Mit Archiven bräuchte man dann
> irgend ein Tool das die dann aus den entsprechenden Dateien extrahiert.

was aber für jemand der Programmieren kann überhaupt kein Aufwand ist.

Autor: Tek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter II schrieb:
> was aber für jemand der Programmieren kann überhaupt kein Aufwand ist.

Nachdem ich mir die Antworten hier durchgelesen habe ist die Tagesarchiv 
variante auch mein Favorit.
Bisher war es halt recht bequem weil man auch zum "nur Office PC User" 
sagen konnte: Hier such dir Deine Dateien einfach aus der Ordnerstruktur 
raus.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tek schrieb:
> Mit Archiven bräuchte man dann
> irgend ein Tool das die dann aus den entsprechenden Dateien extrahiert.

Egal welche Lösung du bevorzugst, die Software muß in jedem Falle 
angepaßt werden. Ohne Anpassung denkbar wäre allenfalls ein Lösung, die 
bspw. realtime die Archive auf Hardlinks mountet, sodaß die Software 
scheinbar auf eine Ordnerstruktur zugreift.

Autor: ergo70 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt, RIAK KV angucken, oder minio.io wenn die IDs und Metadaten 
eh in einer separaten Datenbank liegen.

Autor: Tek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ergo70 schrieb:
> Wie gesagt, RIAK KV angucken, oder minio.io wenn die IDs und Metadaten
> eh in einer separaten Datenbank liegen.

Schau ich mir mal an, danke!

Autor: Possetitjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:

> Es gibt keinen Grund, wieso ein Dateimanager bei 40.000
> Dateien versagt, wenn z.B. ls funktioniert. Außer
> schlampiger Programmierung mit mies skalierenden
> Algorithmen, und die sollte man auch in Dateimanagern
> nicht verwenden.

Ich glaube, wir brauchen nicht weiter zu streiten.
In der Kritik an stümperhafter, schlecht skalierender
Software sind wir ja einer Meinung.

Mein Punkt war ein ganz anderer: Hier wurde die
Behauptung in die Welt gesetzt, dass "der PC für
sowas eben nicht geeignet" ist -- und diese Aussage
ist schlicht und ergreifend Schwachsinn.

Wer so etwas schreibt, hat aus meiner Sicht entweder
einfach keine Ahnung, oder will provozieren - oder
beides.

Autor: Der Andere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tek schrieb:
> Bisher war es halt recht bequem weil man auch zum "nur Office PC User"
> sagen konnte: Hier such dir Deine Dateien einfach aus der Ordnerstruktur
> raus.

Mit einem installierten 7-zip kannst du das weitgehend auch mit zip 
files.

Ich würde eher die oben vorgeschlagenen 15min oder maximal. 
Stundenarchive benutzen, sonst wirds unübersichtlich.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.