Wert in Ascii Datei ändern, ohne die Datei neu zu schreiben

[GGK_01]

Hallo,

ich habe eine Ascii-Datei, in der ich den Wert für Running auf 1 bz. 0 setzen möchte.
Diesen Wert gibt es jedoch mehrfach, daher bin ich auf dein Eintrag in eckigen Klammern (Bsp. [2]) zur Identifizierung des zu ändernden Eintrages angewiesen.

Meine Frage, wie kann ich denn 1 bzw. 0 für Running setzen, ohne die Datei neu schreiben zu müssen?
(Das Ganze sollte dann in einem GUI möglich sein).
Könnte mir jemand einen Denkanstoss geben?

[02]
Arguments[]=
Runlevel=1
Running=1

[03]
Arguments[]=
Runlevel=1
Running=1

Danke GGK

 

[Marco13]

Ich denke, das sollte mit einer RandomAccessFile möglich sein (speziell mit memory mapped files, also raf.getChannel().map(...))

 

[Gast2]

Warum ist es wichtig, dass die Datei nicht neu geschrieben wird?

Die Datei hat ein .ini Format, das kannst du bspw. mit der Java Configuration API bequem lesen / ändern / speichern.

 

[GGK_01]

@EikeB: da es sich bei der Datei um eine Konfigurationsdatei eines Servers handelt und über Running Prozesse gestoppt bzw. gestartet werden.
Ich möchte nur das ändern was unbedingt notwendig ist...

GGK

 

[Timothy Truckle]

@EikeB: da es sich bei der Datei um eine Konfigurationsdatei eines Servers handelt und über Running Prozesse gestoppt bzw. gestartet werden.
Ich möchte nur das ändern was unbedingt notwendig ist...

GGK

Das ist sehr löblich, aber der Ansatz ist falsch:
Über die API kannst Du sicher stellen, dass Du immer gültige Schlüssel/Werte schreibst. Die RandomAccessFile-Methode ist dagegen gefährlich: was, wenn jemand ein zusätzliches Leerzeichen einfügt? Dann überschreibst Du

Running=1

mit

Running01

...

bye
TT

 

[GGK_01]

also heisst der Ansatz:

Java Configuration API?

GGK

 

[Timothy Truckle]

also heisst der Ansatz:

Java Configuration API?

GGK

Ja, falls die Funktionalität von [JAPI]Properties[/JAPI] nicht reicht.

bye
TT

 

[GGK_01]

OK...danke sehr

GGK

 

[GGK_01]

Die Lösung mit den Properties funktioniert schon mal nicht...
da beim Speichern des geänderten Wertes die Datei neu geschrieben wird...

GGK

 

[Timothy Truckle]

Die Lösung mit den Properties funktioniert schon mal nicht...
da beim Speichern des geänderten Wertes die Datei neu geschrieben wird...

Hast Du den den bestehenden Inhalt der Datei zuerst in das Properties-Objekt eingelesen?

bye
TT

 

[GGK_01]

nein...mit load...dann mit save wieder ausgeben?

 

[Timothy Truckle]

nein...mit load...dann mit save wieder ausgeben?

genau.

bye
TT

 

[GGK_01]

      FileOutputStream propOutFile = new FileOutputStream( filename );
	      Properties p1 = new Properties();
	      p1.setProperty( "Running", "2" );
	      p1.store( propOutFile, "Test Info" );
	      FileInputStream propInFile = new FileInputStream( filename );
	      Properties p2 = new Properties();
	      p2.load( propInFile );
	      p2.list( System.out );
	     }

auch damit wird ein neues File erzeugt...leider

 

[bone2]

Selbst wenn du die Datei mit einem Editor öffnest, wird sie komplett neu geschrieben.
Dann musst du da manuell über RandomAccess rangehen.

 

[SlaterB]

was schwierig wird da bytesbasiert, nicht genau chars zu fassen sind,

es bleibt dabei, Einlesen, Ändern, Speichern, ob manuell oder mit Hilfe von Tools wie Properties,
was ganz normales, inwiefern ist das störend? ist doch eine Mini-Datei, merkt man gar nicht,

hat ein anderes Programm parallel Zugriff auf die Datei?
das würde hier wohl genauso Probleme machen wie bei RandomAccessFile


edit:
der Code von 10:40 ist übrigens nicht das wovon zuvor geredet wurde,
erst save, dann load, dann ist nur der eine Wert da,

erst load, dann ändern, dann save -> ein Wert geändert, Rest weiter vorhanden

 

[GGK_01]

stimmt...das listening hab ich etwas zu gekürzt...

folgendes:
in der properties.txt sind folgende Einträge:

Running=1
Debug=2
Level=3

dann starte ich das Programm:

String filename = "D:/tmp/properties.txt";
	    try
	    {
	      
	      FileOutputStream propOutFile = new FileOutputStream( filename );
	      FileInputStream propInFile = new FileInputStream( filename );
	      Properties p1 = new Properties();
	      p1.load(propInFile);
	      p1.setProperty( "Running", "1" );
	      p1.store( propOutFile, "Test Info" );
	      
	      Properties p2 = new Properties();
	      p2.load( propInFile );
	      p2.list( System.out );
	      propOutFile.close();
	      propOutFile.close();
	     }
	     catch ( FileNotFoundException e ) {
	       System.err.println( "Can’t find " + filename );
	     }
	     catch ( IOException e ) {
	       System.err.println( "I/O failed." );
	     }

properties.txt nach dem Durchlauf:

#Test Info
#Fri Feb 08 13:06:19 CET 2013
Running=1

ja, Serverprozesse greifen laufend auf die Datei zu...
die Datei hat ca. 100 Zeilen, die nicht alle in der Form Variable=Wert vorliegen, und ich möchte diese unverändert lassen

 

[SlaterB]

wenn es nicht ginge, wäre das ja nun kein extremer Beinbruch, man kann auch auf andere Weise die Datei einlesen,

das Problem ist hier, dass die Zeile
> FileOutputStream propOutFile = new FileOutputStream( filename );
so früh steht, an dieser Stelle wird bereits die Datei gelöscht, leer neu erstellt,
danach dann nur leer gelesen, da muss man aufpassen

----

> die Datei hat ca. 100 Zeilen, die nicht alle in der Form Variable=Wert vorliegen, und ich möchte diese unverändert lassen

BufferedReader + Writer wohl eher, wie anfangs geschrieben wissen welche Zeile, welche Zeichen,
eigentlich kein Thema für Wochen und Monate..

 

[GGK_01]

stimmt...

FileOutputStream propOutFile = new FileOutputStream( filename );
p1.store( propOutFile, "Test Info" );

löste das Problem...

 

[SlaterB]

zweimal aus demselben FileInputStream, propInFile, zu lesen, ist übrigens auch recht gewagt,
hätte ich geraten hätte ich getippt dass das nicht ginge,
ach geht ja auch gar nicht du schaust im Moment sicher direkt in die Datei

 

[Crian]

Wenn andere Prozesse auf die Datei zugreifen, solltest du sie während der Bearbeitung vor Zugriffen schützen. Stichwort: Semaphore.

 

[GGK_01]

ich hab jetzt noch das Problem, dass die Reihenfolge der Einträge innerhalb properties.txt nach dem Ändern durcheinander geworfen werden.

properties.txt vor Programmstart:

[1]
Argument[]=
Running=1
Level=2
Debug=3

[2]
Argument[]=
Running=21
Level=22
Debug=23

properties.txt nachProgrammstart:

#
#Fri Feb 08 13:43:08 CET 2013
Running=1
[1]=
[2]=
Level=22
Argument[]=
Debug=23

gibt es dazu vielleicht hinweise?

GGK

 

[SlaterB]

einfach suchen, 'java properties order', oder es anderen überlassen..

an sich scheint es eine unsortierte Map zu sein, es sollte dich besser auch nicht kümmern,
wenn du aber die Datei nach Speichern anschauen/ manuell bearbeiten musst, dann schon verständlich

hier ein mehr oder weniger vertrauenswürdiges Konzept zur festen Order (LinkedProperties)
configuration - Pulling values from a Java Properties file in order? - Stack Overflow

------

deine Property-Datei-Vorlage sieht verdächtig aus:
auf Spezialitäten wie eckige Klammern verzichte lieber komplett, auch Zahlen bei den Keys müssen nicht unbedingt sein,
(aber wenn es getestet geht, dann bitte)

absolut unmöglich ist eine Aufteilung in Abschnitte und dann gar wiederholend die gleichen Properties,
es ist einfaches Key=Value-Konzept, damit fallen deine Wünsche unter den Tisch

verwende mehrere Properties-Dateien oder

one.Argument=
one.running=1
one.level=2
one.debug=3

two.argument=
two.running=21
two.level=22
two.debug=23

die Punkt-Notation ist bekannter Standard,
(das heißt aber nicht dass Properties dir eine Methode a la 'gib alle Properties zu 'one' ' bereitstellt)

alle Nicht Key-Value-Zeilen solltest du als Kommentar mit # beginnen lassen,
beim Speichern kommen die aber wohl wieder an den Anfang (edit: werden gar gelöscht, also nicht eingelesen..),
Leerzeilen bleiben auch nicht bestehen usw.

da musst du schon viel schlucken, oder BufferedReader

 

[GGK_01]

ist ja so, dass ich eine vorgebene Datei habe, in der ich nur den Wert für Running auf 0 oder 1 setzen will...

ich versuche über die Propteries das umzusetzen...falls das nciht funktioniert...versuche ich mich über die
java configuration api oder random access an die Lösung zu tasten.

Bps. der Datei:

[02]
Arguments[]=
Runlevel=1
Running=1

[03]
Arguments[]=
Runlevel=1
Running=1

 

[SlaterB]

siehe auch edits in meinem letzten Posting, wobei das meiste, etwa der Hinweis dass keine Properties doppelt vorkommen dürfen,
von Anfang an drin stand, also so gehts nicht mit Properties,

das Format der Datei ist wohl nicht zu verhandeln?
wer verwendet überhaupt das Format, hast du Java-Code zur Auswertung, wird dort eingelesen, wird dort das Running-Level extrahiert?
das wäre dann ja eine gute Vorlage für Lesen, Ändern, Speichern

 

[GGK_01]

nein...ich weiss nur, dass das in c++ passiert...den quellcode hab ich nicht zugänglich...leider