Sicheres Löschen (solved) (Allgemeines zu Perl)

[thread]18257[/thread]

Sicheres Löschen [solved]

Tags: perl5 unlink Similar Threads

Readers: 23

Articles: hide open all | hide show old branches

+26 replies
bianca

2013-04-07 09:48
User since
2009-09-13
7016 articles
BenutzerIn
Hi!
Habe hier ein klitzekleines Problemchen mit Dateiumgang.
Folgendes Testscript:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#!/usr/bin/perl -w use strict; use warnings; use Fcntl qw (:DEFAULT :flock); my $datei = '/meinpfad/test.dat'; my $err; sysopen(my $fh,$datei,O_RDONLY) or $err = $!; if (!defined $err) { my $flock = flock($fh,LOCK_EX|LOCK_NB); if ($flock) { print "Geht los\n"; my $ul = unlink($datei); print "unlink: $ul - >$!<\n"; } else { print "Anderweitig gesperrt\n"; } }
Nun verhält sich das obige Script wie folgt:
Auf Windows 7 mit Strawberry 5.10.1:

Quote
Geht los
unlink: 0 - >Permission denied<

Auf einem Linux Server mit v5.10.1 (*) built for x86_64-linux-gnu-thread-multi:

Quote
Geht los
unlink: 1 - >Inappropriate ioctl for device<

Was will ich damit sagen? Ich suche eine Möglichkeit, eine Datei nur dann zu löschen, wenn sie 1. leer, also -z ist und 2. garantiert von keinem anderen Prozess im Zugriff ist.
Das Beispielscript zeigt, dass das unlink auf Windows erkennt, dass noch ein Zugriff erfolgt und löscht nicht. Auf dem Linux hingegen grätscht das unlink anscheinend in jeglichen Zugriff hinein und löscht gnadenlos. Zwar wird $! gesetzt aber das nützt mir nach dem unlink ja nichts mehr.

Frage 1: Verhält sich das bei euch auch so oder ist das eine Besonderheit des hier getesteten Linux Servers?
Frage 2: Habe ich eine Chance, auf Linux ein "sicheres" Löschen zu verwirklichen?
Danke
10 print "Hallo"
20 goto 10
- topeg
  
  2013-04-07 12:51
  User since
  2006-07-10
  2611 articles
  BenutzerIn
  Wenn du wissen willst welche Dateien geöffnet sind musst du Tools wie lsof nutzen oder dich durch /proc/ arbeiten.
  
  Willst du "lsof" nicht nutzen kannst du das auch so machen:
  
  Code (perl): (dl )
  
  my %opened=map{ $_ => 1 }grep{ !/^\w+:\[?\w+\]?$/ }map{ readlink }glob( "/proc/*/fd/*" );
  
  Das kann aber nur Dateien finden auf die der Prozess zugriff hat.
  
  Und ja das ist ein Linux/Unix Ding.
  Linux ist ein unixartiges System. Diese sind für den Multiuserbetrieb ausgelegt. Aus dem Grund ist es möglich geöffnete Dateien zu löschen. Wenn das nicht möglich wäre gäbe es immer die Gefahr, das bei einem Update, oder dem löschen/ändern eines Benutzeraccounts, oder beim verwenden von Programmen die Gefahr, das es Inkonsistenzen in den Dateiversionen gibt. Die einzige Lösung ist, das Filehandle (und den Inhalt) zu erhalten, aber den Dateinamen aus dem Dateisystem zu entfernen (oder neu zu vergeben).
  
  Das habe ich schon genutzt um einen Festplatten Cache für Programme zu erzeugen. Man legt eine Datei an, öffnet sie und löscht sie. Das Filehandle ist noch vorhanden und nutzbar, aber die Datei ist nicht mehr im Dateisystem. Terminal-Programme nutzen das auch. Das sieht dann so aus: /tmp/vteCBQ7UW (deleted)
- Raubtier
  
  2013-04-07 13:00
  
  User since
  2012-05-04
  1075 articles
  BenutzerIn
  
  Hallo Bianca,
  
  du hast ja immer merkwürdige Probleme :-)
  
  Unter Windows:
  Du öffnest die Datei - und dann kannst du sie nicht löschen. Das ist soweit klar, denn soweit ich mich richtig erinnere, kann man unter Windows offene Dateien nicht löschen. Du öffnest und lockst sie aber (locking ist allerdings immer noch vom Dateisystem abhängig und funktioniert auch nur, wenn auch alle anderen Programme locken - es tut hier also nicht das, was du willst) - somit ist sie offen und kann nicht gelöscht werden.
  
  Unter Linux:
  Man kann offene Dateien löschen. Der Prozess, der die Datei geöffnet hat, kann weiterhin darin lesen oder schreiben, aber beim Schließen ist die Datei dann weg. Das ist eben anders als bei Windows. Du kannst aber mit dem lsof-Kommando sehen, welche Dateien gerade geöffnet sind. Mit lsof +L1 siehst du, welche Dateien gerade offen, aber gelöscht sind.
  
  Und ein Hinweis zu dem ">Inappropriate ioctl for device<": das solltest du komplett ignorieren! Denn der Wert von $! ist nur bei Fehlern aussagekräftig (er kommt auch schon vom sysopen). Da aber kein Fehler aufgetreten ist, bringt er dir nichts.
  
  Zur eigentlichen Frage: Dein Problem ist allgemein nicht zu lösen (denk auch mal an bestimmte Netzwerkdateisysteme, wo dir auch das lsof nichts bringen wird, wo du ggf. nicht einmal genau weißt, wo die Datei überhaupt gespeichert ist). Hast du vielleicht ein anderes, einfacheres Problem? Also zum Beispiel soll die Datei nur von ein paar Instanzen desselben Programmes gelöscht werden? Dann könntest du eine andere Datei flocken (z.B. irgendwas im temp. Verzeichnis) und abhängig davon löschen.
- +5 replies
- pq
  
  2013-04-07 13:44
  
  User since
  2003-08-04
  12208 articles
  Admin1
  
  2013-04-07T07:48:47 bianca
  Auf dem Linux hingegen grätscht das unlink anscheinend in jeglichen Zugriff hinein und löscht gnadenlos. Zwar wird $! gesetzt aber das nützt mir nach dem unlink ja nichts mehr.
  
  wie kommst du darauf? wie lange arbeitest du schon mit perl?
  $! ist nur bei fehlern aussagekräftig. wenn das unlink erfolgreich ist, hat dich $! nicht zu interessieren. da steht immer irgendwas drin.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +4 replies
  - Raubtier
    
    2013-04-07 13:48
    
    User since
    2012-05-04
    1075 articles
    BenutzerIn
    
    2013-04-07T11:44:44 pq
    2013-04-07T07:48:47 bianca
    Auf dem Linux hingegen grätscht das unlink anscheinend in jeglichen Zugriff hinein und löscht gnadenlos. Zwar wird $! gesetzt aber das nützt mir nach dem unlink ja nichts mehr.
    
    wie kommst du darauf? wie lange arbeitest du schon mit perl?
    $! ist nur bei fehlern aussagekräftig. wenn das unlink erfolgreich ist, hat dich $! nicht zu interessieren. da steht immer irgendwas drin.
    
    Wie ich schon schrieb: das $! wird vom sysopen gesetzt (nur eben in Biancas Programm nicht ausgegeben). Ist aber eben völlig irrelevant.
    
    Edit: warum ist das eigentlich so? Ich würde aus Performancegründen erwarten, dass $! nicht angefasst wird, wenn kein Fehler auftritt. Oder macht sysopen intern irgendwas, das diesen Fehler verursacht, der aber für den sysopen-Erfolg irrelevant ist?
    Last edited: 2013-04-07 14:09:41 +0200 (CEST)
    - +3 replies
    - pq
      
      2013-04-07 15:05
      
      User since
      2003-08-04
      12208 articles
      Admin1
      
      2013-04-07T11:48:59 Raubtier
      Wie ich schon schrieb: das $! wird vom sysopen gesetzt (nur eben in Biancas Programm nicht ausgegeben). Ist aber eben völlig irrelevant.
      
      Edit: warum ist das eigentlich so? Ich würde aus Performancegründen erwarten, dass $! nicht angefasst wird, wenn kein Fehler auftritt. Oder macht sysopen intern irgendwas, das diesen Fehler verursacht, der aber für den sysopen-Erfolg irrelevant ist?
      
      $! wird nur im fehlerfall gesetzt. ansonsten enthält es "irgendwas". warum sysopen es setzt, müsstest du mir noch erklären.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - +2 replies
      - Raubtier
        
        2013-04-07 18:45
        
        User since
        2012-05-04
        1075 articles
        BenutzerIn
        
        2013-04-07T13:05:37 pq
        $! wird nur im fehlerfall gesetzt. ansonsten enthält es "irgendwas". warum sysopen es setzt, müsstest du mir noch erklären.
        
        Keine Ahnung. Aber ich habe vor und hinter dem sysopen ein say $! gemacht, und davor war es leer, danach hatte es diesen anderen String enthalten. Warum auch immer. Obwohl sysopen etwas wahres zurückgegeben hat.
        
        topeg
        
        2013-04-07 19:49
        
        User since
        2006-07-10
        2611 articles
        BenutzerIn
        
        Das ist nicht so verwunderlich.
        
        So versucht die GNU C Library beim öffnen einer Datei ein paar Flags zu setzen um den Daten Transfer zu beschleunigen (Transferblockgröße z.B.). Mache Flags sind *BSD oder Windows spezifisch. Auch unterstützen nicht alle Kernel alle Flags, oder sie sind für bestimmte Benutzer gesperrt. Dann gibt es noch Flags die lassen sich nur auf bestimmte Dateien anwenden. Es hängt auch vom Compiler (und den Optionen) ab welche Flags überhaupt zulässig sind.
        So was findet man häufiger in der GNU C Library und ist auch einer der Kritikpunkte an der Lib.
        
        Auch wenn perl nicht immer auf die libc zurück greift, so handelt sie intern ähnlich um möglichst viele Betriebssysteme abzudecken.
- +18 replies
- bianca
  
  2013-04-07 15:16
  
  User since
  2009-09-13
  7016 articles
  BenutzerIn
  
  Danke für alle Antworten.
  Zum Hintergrund: Das Dateihandling ist gekapselt in einer sub. Diese sub macht in dieser Reihenfolge folgendes:
  1. sysopen
  2. flock
  3. binmode
  4. seek
  5. readline
  6. truncate
  7. print
  8. close
  9. unlink if -z
  
  Und genau damit ist mir letztens eine Datei verloren gegangen. War nur ein unwichtiger Chat aber schon bei zwei Leuten hat das unlink offensichtlich einmal mitten rein gegrätscht, denn plötzlich war der Chat leer :(
  
  Mal davon abgesehen, dass man das mit einer DB sicher einfacher hinbekommt und auch die Frage berechtigt ist, warum ich leere Dateien nicht haben will, möchte ich trotzdem gern das Problem lösen.
  Daher mal ganz allgemein, wie würdet ihr das machen?
  Weitere Prämisse: Es bestehen keine Admin-Rechte!
  Danke für alle Tipps.
  10 print "Hallo"
  20 goto 10
  - +4 replies
  - topeg
    
    2013-04-07 17:27
    User since
    2006-07-10
    2611 articles
    BenutzerIn
    
    Wie ich schon schrieb, du musst halt prüfen ob die Datei noch geöffnet ist.
    
    Code (perl): (dl )
    
    1 2 3 4 5 6
    
    # close ... my %opened; if($^O=~/linux/i) { %opened=map{ $_ => 1 }grep{ !/^\w+:\[?\w+\]?$/ }map{ readlink }glob( "/proc/*/fd/*" ); } unlink $file if(-z $file and !$opened{$file});
    - +3 replies
    - bianca
      
      2013-04-08 12:32
      
      User since
      2009-09-13
      7016 articles
      BenutzerIn
      
      Hmm, wenn ich so recht drüber nachdenke liegt in dem linuxidalen Verhalten ja eigentlich schon meine Lösung.
      Denn wenn ich sicherstelle, dass 1. alle Prozesse konsequent flock'en und 2. ich eine Datei flock'en kann, dann weiß ich ja, dass gerade kein anderer Prozess drauf zugreifen kann.
      Dann kann ich sie doch löschen, oder?
      Habe ich einen Denkfehler?
      10 print "Hallo"
      20 goto 10
      - +2 replies
      - guest wer
        
        2013-04-08 13:51
        
        Sicher geht das auch so:
        
        Öffnen
        Locken
        Löschen if -z
        Schließen
        
        Unter Windows bekommst du mit der Reihenfolge Probleme.
        
        Wenn du erst schließt und dann löschst kann ein anderer Prozess diese ja schon wieder öffnen.
        Last edited: 2013-04-08 14:06:14 +0200 (CEST)
        
        bianca
        
        2013-04-10 07:01
        
        User since
        2009-09-13
        7016 articles
        BenutzerIn
        
        Guest wer
        Sicher geht das auch so:
        
        Öffnen
        Locken
        Löschen if -z
        Schließen
        
        Das ist ja genau die Reihenfolge aus meinem Testscript. Bis auf das Schließen - das ist implizit - mache ich es auch genau so. Und auf Windows muss ich mir was überlegen.
        Danke allen!
        10 print "Hallo"
        20 goto 10
  - +13 replies
  - thomas38
    
    2013-04-24 00:56
    
    User since
    2012-11-04
    30 articles
    BenutzerIn
    
    2013-04-07T13:16:36 bianca
    Danke für alle Antworten.
    Zum Hintergrund: Das Dateihandling ist gekapselt in einer sub. Diese sub macht in dieser Reihenfolge folgendes:
    1. sysopen
    2. flock
    3. binmode
    4. seek
    5. readline
    6. truncate
    7. print
    8. close
    9. unlink if -z
    
    Und genau damit ist mir letztens eine Datei verloren gegangen. War nur ein unwichtiger Chat aber schon bei zwei Leuten hat das unlink offensichtlich einmal mitten rein gegrätscht, denn plötzlich war der Chat leer :(
    
    Mal davon abgesehen, dass man das mit einer DB sicher einfacher hinbekommt und auch die Frage berechtigt ist, warum ich leere Dateien nicht haben will, möchte ich trotzdem gern das Problem lösen.
    Daher mal ganz allgemein, wie würdet ihr das machen?
    Weitere Prämisse: Es bestehen keine Admin-Rechte!
    Danke für alle Tipps.
    
    Du öffnest die Datei (Schritt 1) und versuchst anschließend ein flock (Schritt 2). Somit ist sie bereits geöffnet.
    
    Meine Empfehlung:
    Eine eigene Lock-Datei beim Start des Programms anlegen, sofern sie noch nicht existiert (als _ein_ Systemaufruf). Es ist kein Fehler, wenn die Datei bereits existiert.
    
    Anschließend diese Datei (Inhalt egal) in Deiner sub als Lockdatei verwenden, _bevor_ mit sysopen die Datendatei geöffnet wird.
    Wenn alle Operationen mit der Datendatei beendet sind, kann der Lock auf die Lockdatei wieder freigegeben werden. Die Lockdatei darf natürlich nicht gelöscht werden.
    Das Löschen der Lockdatei kann beim Programmende durchgeführt werden.
    
    Allerdings können so andere Prozesse die Datei natürlich öffnen, die mit Deinem Programm nichts zu tun haben. Unter Windows hast Du dann das Pech, dass diese Datei trotzdem nicht gelöscht werden kann, obwohl _Dein_ Programm die Datendatei nicht im Zugriff hat.
    - +12 replies
    - bianca
      
      2013-04-24 06:12
      
      User since
      2009-09-13
      7016 articles
      BenutzerIn
      
      2013-04-23T22:56:34 thomas38
      Du öffnest die Datei (Schritt 1) und versuchst anschließend ein flock (Schritt 2). Somit ist sie bereits geöffnet.
      Ja, und weiter?
      Darin lag ja nicht das Problem, wie sich herausgestellt hat.
      
      2013-04-23T22:56:34 thomas38
      Meine Empfehlung:
      Eine eigene Lock-Datei beim Start des Programms anlegen, sofern sie noch nicht existiert (als _ein_ Systemaufruf). Es ist kein Fehler, wenn die Datei bereits existiert.
      Es geht hierbei nicht nur um eine Datei sondern um eine beim Programmstart noch nicht bekannte Anzahl Dateien.
      10 print "Hallo"
      20 goto 10
      - +11 replies
      - Raubtier
        
        2013-04-24 09:39
        
        User since
        2012-05-04
        1075 articles
        BenutzerIn
        
        Thomas schlägt die ein Locking vor mithilfe einer zusätzlichen, festen Datei vor.
        
        Du lockst also nicht die zu löschende(n) Datei(en), sondern genau eine andere. Das machen alle Teile deiner Scripte, die löschen möchten. Da nur eine Instanz den Lock haben kann, kannst du dann sicher sein, dass der Löschteil im Programm nur in einer Instanz des Programms gleichzeitig läuft.
        
        Edit:
        Das habe ich übrigens auch schon so vorgeschlagen am Ende von msg #166923
        Last edited: 2013-04-24 09:41:13 +0200 (CEST)
        
        +7 replies
        
        bianca
        
        2013-04-24 10:23
        
        User since
        2009-09-13
        7016 articles
        BenutzerIn
        
        2013-04-24T07:39:59 Raubtier
        Thomas schlägt die ein Locking vor mithilfe einer zusätzlichen, festen Datei vor.
        
        Ja, habe ich verstanden. Wie gesagt, es geht nicht nur um eine Datei und ich habe keine Lust, mir ein Paralleluniversum an Dateien aufzubauen :)
        Für Linux ist es ja damit gelöst, dass ich die Datei nur lösche, wenn sie ge'flock't ist.
        Für Windows ist es mir im Moment egal.
        Trotzdem danke
        10 print "Hallo"
        20 goto 10
        
        +6 replies
        
        Raubtier
        
        2013-04-24 15:03
        
        User since
        2012-05-04
        1075 articles
        BenutzerIn
        
        2013-04-24T08:23:47 bianca
        Ja, habe ich verstanden.
        
        Ich denke nicht (oder ich verstehe dich nicht).
        
        Quote
        Wie gesagt, es geht nicht nur um eine Datei und ich habe keine Lust, mir ein Paralleluniversum an Dateien aufzubauen :)
        
        Das ist ja auch nicht der Fall. Es gibt genau eine andere Datei. Das sollte auch unter Windows funktionieren.
        
        +5 replies
        
        bianca
        
        2013-04-24 17:08
        
        User since
        2009-09-13
        7016 articles
        BenutzerIn
        
        2013-04-24T13:03:44 Raubtier
        Das ist ja auch nicht der Fall. Es gibt genau eine andere Datei.
        
        Also: Ich habe ein Verzeichnis mit geschätzen 1000 Dateien. Auf jeder dieser Dateien kann einer von geschätzen 40 verschiedenen Scripten hängen.
        Das Script um das es in diesem Thread geht soll von diesen 1000 nun alle löschen, die 0 Byte groß sind UND nicht gerade von einem dieser anderen Prozesse belegt sind.
        Jetzt erklär mir bitte nochmal, wie ich das mit einer EINER Lock-Datei löse. Ich hab es nicht verstanden.
        10 print "Hallo"
        20 goto 10
        
        +2 replies
        
        pq
        
        2013-04-24 17:18
        
        User since
        2003-08-04
        12208 articles
        Admin1
        
        wenn du 40 verschiedene skripte hast, die sich alle mit denselben dateien beschäftigen, und wenn du keinen gemeinsamen code hast, der den zugriff darauf kapselt (dann könntest du das locking mit der lockdatei zentral in einem modul machen), dann machst du was falsch.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        bianca
        
        2013-04-24 17:34
        
        User since
        2009-09-13
        7016 articles
        BenutzerIn
        
        2013-04-24T15:18:59 pq
        wenn du 40 verschiedene skripte hast, die sich alle mit denselben dateien beschäftigen, und wenn du keinen gemeinsamen code hast, der den zugriff darauf kapselt (dann könntest du das locking mit der lockdatei zentral in einem modul machen), dann machst du was falsch.
        
        Ja, stimme ich zu. Ist eine gewachsene Struktur wo ich mit den Gegebenheiten klar kommen muss. Die einzige Gemeinsamkeit ist, dass alle Scripte ihre Datei jeweils flock'en (wenigstens das ist gegeben).
        
        Aber nochmal: ES IST BEREITS GELÖST! :)
        
        Der Trick, die Datei erst zu flock'en und dann zu unlink'en funktioniert auf Linux super.
        10 print "Hallo"
        20 goto 10
        
        +2 replies
        
        Raubtier
        
        2013-04-24 18:36
        
        User since
        2012-05-04
        1075 articles
        BenutzerIn
        
        Die Idee war, alle Dateioperationen mit einer Lockdatei abzusichern. Das löst dein Problem dann nicht, wenn du die Löschungen benötigst, während auf einen Teil der Dateien zugegriffen wird.
        
        Es löst das Problem dann, wenn du es dir erlauben kannst, für alle Dateioperationen global zu locken. Oftmals ist das gegeben. Durch den Lock wüsstest du dann, dass genau 0 von deinen Dateien gerade irgendwo im Zugriff sind. Und dann könntest du diese Dateien alle löschen.
        
        Locks auf 1000 verschiedene, vielleicht sogar leere Dateien hört sich verdammt verkehrt an. Um was für ein Dateisystem handelt es sich überhaupt? Wenn es eine lokale Festplatte ist, kann die nämlich sowieso nicht bei 1000 Dateien gleichzeitig lesen und/oder schreiben, daher könnte es sein, dass es nicht langsamer ist, alle Dateioperationen nacheinander auszuführen (könnte vielleicht sogar schneller sein, je nachdem, was du so machst). Handelt es sich um ein paralleles Dateisystem, sieht die Sache natürlich anders aus. Dort sind oft lesen/schreiben recht billig, aber
        öffen und locken (sofern überhaupt unterstützt) oft recht teuer.
        
        bianca
        
        2013-04-24 18:39
        
        User since
        2009-09-13
        7016 articles
        BenutzerIn
        
        Danke für deine Zeit aber ich möchte wirklich nicht mehr drauf eingehen, denn es ist längst gelöst.
        10 print "Hallo"
        20 goto 10
        
        +3 replies
        
        rosti
        
        2013-04-24 16:20
        
        User since
        2011-03-19
        3463 articles
        BenutzerIn
        
        Die Idee 'Zentralverriegelung' ist gut!
        
        Gibts be mir schon länger:
        
        Code (perl): (dl )
        
        use Lock;
        
        und schon ist der Prozess atomar, fertig ;)
        
        --Rosti
        
        +2 replies
        
        Raubtier
        
        2013-04-24 16:30
        
        User since
        2012-05-04
        1075 articles
        BenutzerIn
        
        Man wird aber wohl oft nicht gleich den ganzen Prozess locken wollen, sondern nur die Teile, die mit der Dateibehandlung zu tun haben. Der Rest soll ja meistens parallel laufen. Daher erscheint mir ein "use Lock", was auch immer du darin genau machst, erstmal etwas unangebracht. Es sei denn, du hast darin eine Funktion, die zum Beispiel "getGlobalLock()" heißt und deren Rückgabewert zum Beispiel das gelockte Dateihandle ist. Dann hätte man also
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8
        
        sub mach_was_mit_dateien { irgendwas_das_kein_lock_braucht; { my $lock = Lock::getGlobalLock(); operationenen_die_lock_brauchen; } rest_der_kein_lock_braucht; }
        
        oder so ähnlich. Sobald das $lock aus dem Scope raus ist, wird der Lock wieder aufgehoben.
        Last edited: 2013-04-24 16:32:36 +0200 (CEST)
        
        rosti
        
        2013-04-24 16:39
        
        User since
        2011-03-19
        3463 articles
        BenutzerIn
        
        Quote
        Man wird aber wohl oft nicht gleich den ganzen Prozess locken wollen, sondern nur die Teile, die mit der Dateibehandlung zu tun haben.
        
        Richtig, wegen der Performance. Die betroffenen 'Programmteile' werden bei mir über Kontrollstrukturen aufgerufen, im Falle von Webanwendungen sind das Parameter-Kontrollstrukturen.
        
        Beispielsweise ein Login-Prozess, der nur dann atomar schreiben muss, wenn die Credentials richtig eingegeben wurden.
        
        --Rosti

View all threads created 2013-04-07 09:48.