C - Datei verändern

C - Datei verändern (34 Beiträge, 419 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo den C Spezialisten unter uns.

Kurze Zusammenfassung des Problems: Ich habe eine Datei die mit 50 MB für ein Embedded System nicht gerade klein ist. Ich müsste diese Datei nun soweit verändern dass vorne und hinten etwas hinzugefügt werden muss.

Nun wollte ich fragen ob es in C eine Möglichkeit dazu gibt. Das Append sollte nicht so das Problem sein, mir macht mehr der Teil vorne Kopfzerbrechen. Gibt es für dieses Problem eine praktikable Lösung oder soll ich den Standardweg gehen und eine neue Datei erstellen und diese dann mit den Inhalten der alten füllen?

Danke

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

du hast EIN quelltextfile mit 50MB größe?

soviel quelltext hat wenn ichs recht im kopf hab nichtmal der windowskernel...

Wo hab ich gesagt dass es ein Quelltextfile ist?

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

sorry c - datei klang nach quelltextfile :p

btw: die entpackten Linux Kernel Sourcen sind größer

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

die datei enthält wohl messwerte oder?

irgendwie wärs interessant zu wissen wieso vorne was dran gehört.

beim rätselraten fällt mir nur ein das solche werte ja meist chronologisch aufgenommen werden und eben somit am ende landen.

auch ists meist einfacher die lese-anwendung anzupassen als solche files zu verschieben oder umzubauen.

messwerte

Nein, einen Video Stream

wieso vorne was dran gehört

Kennst den MPEG4 Container? Ist aufgebaut aus sogenannten Atoms die unter anderem auch die Größe des nachfolgenden Datenblocks beinhalten. Das Problem das ich habe ist nun dass ich erstmal die einzelnen Frames bekomme und erst danach den Atom - Tree aufbauen kann. Klar, ich könnte jeweils die Size Information leer lassen und mir eine Referenz drauf merken, aber ich könnte mir vorstellen, dass das recht kompliziert werden kann (Atoms können ineinander verschachtelt werden usw.).

meist einfacher die lese-anwendung anzupassen

In diesem Fall nicht, die Lese Anwendung ist sozusagen in Hardware ausgeführt

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

04.03.2008, 21:02 Uhr - Editiert von Somnatic, alte Version: hier

langsam verstehe ich dein problem

ich kenne das leider nur in der von dir schon erwähnten version einfach einigen platz am anfang zu reservieren und dann aufzufüllen, zur not mit dummydaten die nicht verwendet werden falls man zuviel genommen hat.

ideal is das wohl nicht.

ansonst tät mir nur ein zugriff über das dateisystem einfallen. aber das wird ja je nach system auch wieder komplexer. außerdem könnts die fragmentierung erhöhen bzw die könnte allgemein ein problem dabei darstellen und das sehr komliziert machen.

wohl nicht

Eben net, die Dinger sind recht verschachtelt .. da hast schonmal 20-30 solcher Atoms in 5 Levels drin - nicht schön .. schon gar nicht wenn sämtliche Größeninformationen voneinander abhängen

Aber die Sache mit dem "mit Dummy Info füllen" wäre eine Möglichkeit. Was muss die HW auch so einen dummen Short Header mitliefern ...

zugriff über das dateisystem einfallen

Du meinst dass ich das sogar noch unter die Dateisystemebene gehe? Na, das tu ich mir net an - das wär wirklich Overkill. Davor merk ich mir die Positionen der Atoms

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

ach na geh, ich hätt da gerne eine kreative lösung gesehen

in zeiten von flash und zugriffszeiten gegen 0 wäre eine art linked-list dateisystem ja mal erfindenswert :D

keine Angst .. ich hab mit FAT, JFFS2 und Co. schon genug zu tun

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

??? du bastelst an MPEG4 Files herum + stellst eine solche C-Frage ?!?
solche Baum- oder Track-basierten Formate auf eigene Faust zu handhaben ist ein bißchen das Rad neu erfinden, denn mit ffmpeg / VLC / mpeg4ip gibt's einen haufen Libs, die das erledigen bzw. als Basis dienen können.

muß es mangels Memory unbedingt quasi-sequentiell sein, statt Baum + dann die Blöcke / Tracks wieder einsammeln und auffädeln?

umgekehrt: mir ist kein OS mit insert-Semantik im fopen/fwrite bekannt, falls du auf sowas gehofft hast - anyone else?

du bastelst an MPEG4 Files herum + stellst eine solche C-Frage

Wie du siehst: Ja, habs bis dato nie wirklich gebraucht, mich nicht darum gekümmert. Und wollte halt mal nachfragen obs da evtl. was gibt

auf eigene Faust zu handhaben

Jein, einerseits brauche ich den Baum nur für ein spezielles Format bzw. ein Profile. Das Problem ist jedoch eher die genannten Pakete auf die Zielplattform zu portieren, mit einfach mal neu durchkompilieren ists da im Allgemeinen nicht getan. Außerdem haben die von dir genannten Bibliotheken Probleme den Short Header korrekt auszulesen (MPEG4IP hats als einziger geschafft). Der ist jedoch nicht allzu kompliziert, aber implementieren müsst ichs halt dann sowieso selber.

Was den Speicherbedarf anbelangt. Ich bekomme regelmäßig einzelne, fertig kodierte Frames. Diese starten mit dem VOP Start Bitmuster. Ich muss mir diese dann aus dem HW/SW gemappten Bereich abholen und wegschreiben. Sprich: Hier kommt das Sequentielle ins Spiel. Während nun genug Diskspeicherplatz vorhanden ist, könnts schon so sein dass bei längeren Videos der RAM knapp wird - daher: die Daten müssen weg.
Nun könnte ich natürlich zuerst den Baum aufbauen, hätte dann aber das Problem, dass im jeweiligen atom ja bereits die Größe des Atoms steht (inkl. der untergeordneten atoms). Da wär also die Lösung sich mal eben die Stelle zu merken, an der noch die Größe nachgetragen werden muss. Diese Lösung favorisiere ich derzeit (nachdem ich mir die vorherigen Postings durchüberlegt habe).

Was mir auch noch ein bischen abgeht, ist eine Information, welche Blöcke denn MINIMAL von einem solchen Baum benötigt werden. Momentan arbeite ich hauptsächlich mit Beispiel Files, aber mühsam ist das halt schon. Dann könnte ich mal den Aufwand besser abschätzen.

OS mit insert-Semantik im fopen/fwrite bekannt

Ich wusste nicht dass man das so nennt, aber wenn ichs richtig verstehe: Ja, genau sowas hätte ich gesucht

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Das Problem ist jedoch eher die genannten Pakete auf die Zielplattform zu
portieren, mit einfach mal neu durchkompilieren ists da im Allgemeinen nicht
getan. Außerdem haben die von dir genannten Bibliotheken Probleme den Short
Header korrekt auszulesen (MPEG4IP hats als einziger geschafft).

darf ich neugierig sein, welche Zielplattform das wäre ?

btw: eine Möglichkeit wäre ev. einige Pseudo-Tracks einzubauen, die dann extern (mp4creator o.ä.) in einem späteren Schritt rausoptimiert werden (nachdem ich mich auf einer anderen Ebene mit mpeg4 herumspiele, bin ich mir aber nicht sicher, ob das Format für so einen Workaround eignet)

aber was soll das ganze am Schluß werden? ein streamripper ? ein mp4-Realtime-Recorder?

darf ich neugierig sein, welche Zielplattform das wäre ?

btw: eine Möglichkeit wäre ev. einige Pseudo-Tracks einzubauen, die dann
extern (mp4creator o.ä.) in einem späteren Schritt rausoptimiert werden
(nachdem ich mich auf einer anderen Ebene mit mpeg4 herumspiele, bin ich mir
aber nicht sicher, ob das Format für so einen Workaround eignet)

Hm .. das sagt mir jetzt nicht so zu .. da wär die Sache mit dem Merken evtl. noch einfacher

aber was soll das ganze am Schluß werden?

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

du hast EIN quelltextfile mit 50MB größe?

hab´s auch beim ersten lesen so interpretiert

Dumme Frage vielleicht, aber muss es C sein (z.b. weil du noch mehr mit der Datei machen willst)?

Simples vorne / hinten einfügen / anfügen würde sich sicherlich auch auf der Kommandozeile erledigen lassen, mit einem Shellskript.

Wäre eben simpler und wartungsfreundlicher, als C-Code.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.3 - Firefox Erweiterung für Geizhals User

Ja ich hätte das gerne in einem Tool drin, ansonsten könnte ich ja hintendran einfach den MP4Creator von MPEG4IP dranhängen. Die Lösung habe ich auch bereits durchgedacht, aber momentan bin ich mehr auf der Schiene: Ja, bitte direkt in C

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Das kommt, wie man so schön sagt, drauf an. Auf Dateisystemebene kann man normalerweise keine Daten einfach so vorne an eine Datei dazutun, sondern nur hinten dranhängen. Nur zwingt dich ja niemand dazu, mit einem Dateisystem zu arbeiten. Eine praktikable Lösung wäre also, die Daten physikalisch hintendran oder sonstwohin zu schreiben, aber trotzdem in der gewünschten richtigen Reihenfolge wieder auszulesen. Dann kommst du ohne Kopieraktion aus.

Das kommt, wie man so schön sagt, drauf an

physikalisch hintendran

Ist halt insofern blöd als dass mehrere Dateisysteme zum Einsatz kommen können (FAT am USB Stick, JFFS, überhaupt ein NFS) und dann würde ich eben diese Abstraktionsschicht verlassen.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Schreibst Du da immer an bestimmten Stellen der Datei ?

Weil ansonsten würd ichs einfach via ssize_t read(int fd, void *buf, size_t count); machen.. quasi einlesen quelle/schreiben ziel bis man an den Stellen ist die zu verändern wären => neuer content schreiben => weiterlesen bis man am Ende was attachen will => source close() => dest write...

Kommt halt auch drauf an wieviel du pro "fetch" lesen kannst..

Das wär eben die Lösung die ich gern vermeiden will. Damit hätte ich ja zu zumindest einem Zeitpunkt die Datei 2fach.
Etwas ändern muss ich - wenn mich jetzt grad nicht alles täuscht - nur am Anfang und am Schluss.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

seek mit write ?

Wenns nur was zum Ändern ist sollte das doch reichen ?

ssize_t write(int fd, const void *buf, size_t count);
off_t lseek(int fildes, off_t offset, int whence);

05.03.2008, 09:43 Uhr - Editiert von Knurz, alte Version: hier

Ist eben kein Ändern sondern ein Hinzufügen am Anfang

Wenn ich ein normales write ausführe überschreibt mir das doch einfach den Inhalt der an der Stelle steht.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

sondern ein Hinzufügen am Anfang

Ah ok. Ich nehm an Memory hast ja nicht um die Operation im Speicher durchzuführen ?

Wenn ich ein normales write ausführe überschreibt mir das doch einfach den
Inhalt der an der Stelle steht.

Stimmt, ich ging auch von einem Ändern aus, mit Hinzufügen wirst 2 Dateien imo brauchen.
Bin aber gespannt ob noch ein "C-Crack" eine Lösung findet ohne

nehm an Memory hast ja nicht um die Operation im Speicher durchzuführen

Genau der ist eben knapp

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Embedded halt

Ich würds via Schleife ganz einfach "fetchweise" mit wenigen Bytes einlesen und mich dahinarbeiten bis zu dem Punkt wo was eingefügt werden soll.

Problem ist halt der wenige Speicher, sonst machst das easy im Speicher und schreibst die fertige Datei. Aber irgendwohin müssen ja die 2 "Teile" der Datei wenn Du was einfügst.

05.03.2008, 11:12 Uhr - Editiert von Knurz, alte Version: hier

Die Datei splitten und binär speichern sollte ja gehen, oder!? Wenn man weiß, was man verändern will, dann sollte die Datei wieder lesbar sein.
___________________________

Ich glaube an das Gute im Menschen,
ich verlasse mich aber lieber auf das Schlechte in ihm.

Die Datei splitten

Da hast aber auch kurzzeitig 2 Datein, das wollte er ja nicht

Aber ansonsten hätt ichs auch so gemacht, halt kurzzeitig zerlegen und wieder zusammenbasteln.

Gibt es 'mmap.h' auf dem System?
Annahme je ein MB vorne und hinten anfügen

1) Datei mit append öffnen und hinten zwei MB anfügen (sprich Datei hat jetzt die richtige Länge)

2) mit mmap die Datei in den Speicher mappen (sprich die Datei wird zum Swapfile für den Speicherbereich wenn das RAM knapp werden sollte).

3) mit memmove die Daten nach hinten schieben.

Sag mal, wieviele alte Threads gräbst du denn noch aus?

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung