Hallo,

ich versuche den Zeitstempel diverser Dateien zu ermitteln.

Dabei erhalte ich den Fehler "stat failed for /backup/STEUDAT/DATEV/
DATEV20070527010013.rar (errno=75 - Value too large for defined data
type)". Kann mir da jemand mal nen Tipp geben wo ich mit der Suche
beginne?

Danke Jozsef

juni.jozsef [at] web.de wrote:

> ich versuche den Zeitstempel diverser Dateien zu ermitteln.
>
> Dabei erhalte ich den Fehler "stat failed for /backup/STEUDAT/DATEV/
> DATEV20070527010013.rar (errno=75 - Value too large for defined data
> type)". Kann mir da jemand mal nen Tipp geben wo ich mit der Suche
> beginne?

Wenn Du zeigst was Du tust kann Dir vieleicht auch jemnd sagen was daran
falsch ist. Hellsehen kann hier keiner.

Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

..oO(Ulf Kadner)

>Hellsehen kann hier keiner.

Das wußte ich.

Micha

On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
> juni.joz... [at] web.de wrote:
> > ich versuche den Zeitstempel diverser Dateien zu ermitteln.
>
> > Dabei erhalte ich den Fehler "statfailed for /backup/STEUDAT/DATEV/
> > DATEV20070527010013.rar (errno=3D75 - Value toolargefor defined data
> > type)". Kann mir da jemand mal nen Tipp geben wo ich mit der Suche
> > beginne?
>
> Wenn Du zeigst was Du tust kann Dir vieleicht auch jemnd sagen was daran
> falsch ist. Hellsehen kann hier keiner.
>

Ist doch eigentlich schade, oder? ;-)

Hier die Programmzeilen:

while (false !=3D=3D ($file =3D readdir($handle))) {
$ft =3D filemtime($file);
...
...
...
}

Gruß Jozsef

On 15 Aug., 06:03, juni.joz... [at] web.de wrote:
> On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
>
> > juni.joz... [at] web.de wrote:
> > > ich versuche den Zeitstempel diverser Dateien zu ermitteln.
>
> > > Dabei erhalte ich den Fehler "statfailed for /backup/STEUDAT/DATEV/
> > > DATEV20070527010013.rar (errno=3D75 - Value toolargefor defined data
> > > type)". Kann mir da jemand mal nen Tipp geben wo ich mit der Suche
> > > beginne?
>
> > Wenn Du zeigst was Du tust kann Dir vieleicht auch jemnd sagen was daran
> > falsch ist. Hellsehen kann hier keiner.
>
> Ist doch eigentlich schade, oder? ;-)
>
> Hier die Programmzeilen:
>
> while (false !=3D=3D ($file =3D readdir($handle))) {
> $ft =3D filemtime($file);
> ...
> ...
> ...
> }
>
> Gruß Jozsef


Ich hab den Fehler eingegrenzt.

Es liegt offensichtlich an der Dateigröße.
Der Fehler tritt nur bei Dateien auf, die grüßer als 2GB sind.

Gibt es eine andere Möglichkeit außer mit filectime() oder stat()
an das Dateidatum zu kommen?

Danke Jozsef

juni.jozsef [at] web.de schrieb:
> On 15 Aug., 06:03, juni.joz... [at] web.de wrote:
>> On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
>>
>>> juni.joz... [at] web.de wrote:
>>>> ich versuche den Zeitstempel diverser Dateien zu ermitteln.
>>>> Dabei erhalte ich den Fehler "statfailed for /backup/STEUDAT/DATEV/
>>>> DATEV20070527010013.rar (errno=75 - Value toolargefor defined data
>>>> type)". Kann mir da jemand mal nen Tipp geben wo ich mit der Suche
>>>> beginne?
>>> Wenn Du zeigst was Du tust kann Dir vieleicht auch jemnd sagen was daran
>>> falsch ist. Hellsehen kann hier keiner.
>> Ist doch eigentlich schade, oder? ;-)
>>
>> Hier die Programmzeilen:
>>
>> while (false !== ($file = readdir($handle))) {
>> $ft = filemtime($file);
>> ...
>> ...
>> ...
>> }
>>
>> Gruß Jozsef
>
>
> Ich hab den Fehler eingegrenzt.
>
> Es liegt offensichtlich an der Dateigröße.
> Der Fehler tritt nur bei Dateien auf, die grüßer als 2GB sind.

größer als 2GB oder größer 4GB?


>
> Gibt es eine andere Möglichkeit außer mit filectime() oder stat()
> an das Dateidatum zu kommen?

Ich hab jetzt länger nichts mehr mit PHP unter nem 32Bit OS gemacht,
aber es würde mich wundern, wenn eine aktuelle PHP Version das von dir
beschriebene Problem hat.
Ist es möglich, dass du noch eine sehr alte PHP Version verwendest.

Gruß Stefan
>
> Danke Jozsef
>

juni.jozsef [at] web.de wrote:
> Ich hab den Fehler eingegrenzt.
>
> Es liegt offensichtlich an der Dateigröße.
> Der Fehler tritt nur bei Dateien auf, die grüßer als 2GB sind.
>
> Gibt es eine andere Möglichkeit außer mit filectime() oder stat()
> an das Dateidatum zu kommen?

Eventuell trifft dieser Bug zu:
http://bugs.php.net/bug.php?id=27792

<quote>
Note: Because PHP's integer type is signed and many platforms use 32bit
integers, filesize() may return unexpected results for files which are
larger than 2GB. For files between 2GB and 4GB in size this can usually
be overcome by using sprintf("%u", filesize($file)).
</quote>

Joe

Michael Fesser wrote:
> .oO(Ulf Kadner)
>
>> Hellsehen kann hier keiner.
>
> Das wußte ich.

Das war ja auch mehr an den OP gerichtet. Oder übersehe ich irgendwas
tiefgründiges oder verborgenes in Deiner Antwort?

Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Ulf Kadner wrote:
> Michael Fesser wrote:
>> .oO(Ulf Kadner)
>>
>>> Hellsehen kann hier keiner.
>>
>> Das wußte ich.
>
> Das war ja auch mehr an den OP gerichtet. Oder übersehe ich irgendwas=

> tiefgründiges oder verborgenes in Deiner Antwort?

Ja, er hat IMO deine Aussage "Hellsehen kann hier keiner" dadurch ad
absurdum geführt, daß er angab, daß er im voraus wußte, daß die=
ser Satz
kommen würde. ;-) Nebenbei: Ich halte deine Aussage auch für gewagt, =

weil empirische Resultate durchaus darauf hinweisen, daß Hellsehen
möglich sein könnte, aber das ist ein anderes Thema. ;-)

Grüße,

Alex

Alexander Schestag wrote:
> Ulf Kadner wrote:
>> Michael Fesser wrote:
>>> .oO(Ulf Kadner)
>>>
>>>> Hellsehen kann hier keiner.
>>> Das wußte ich.
>> Das war ja auch mehr an den OP gerichtet. Oder übersehe ich irgendwas
>> tiefgründiges oder verborgenes in Deiner Antwort?
>
> Ja, er hat IMO deine Aussage "Hellsehen kann hier keiner" dadurch ad
> absurdum geführt, daß er angab, daß er im voraus wußte, daß dieser Satz
> kommen würde. ;-)

Ohh! Nachher kann das jeder sagen. ;-)

> Nebenbei: Ich halte deine Aussage auch für gewagt,

Aha...

> weil empirische Resultate durchaus darauf hinweisen, daß Hellsehen
> möglich sein könnte, aber das ist ein anderes Thema. ;-)

Klar! Übrigens morgen treff ich mich mit meinen außerirdischen Nachbarn.
Die sagen zwar sie wären Schwaben, aber das kann ja jeder sagen.
Empirische Resultate zeigen das viele Schwaben nicht von dieser Welt
sind ;-)

SCNR, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_) Mitglied der Freizeitvögel? ;-)
^^

Hallo Ulf,

Ulf Kadner wrote:
> Alexander Schestag wrote:

>> Nebenbei: Ich halte deine Aussage auch für gewagt,

> Aha...

Ja.

>> weil empirische Resultate durchaus darauf hinweisen, daß Hellsehen
>> möglich sein könnte, aber das ist ein anderes Thema. ;-)

> Klar! =DCbrigens morgen treff ich mich mit meinen außerirdischen Nach=
barn.
> Die sagen zwar sie wären Schwaben, aber das kann ja jeder sagen.
> Empirische Resultate zeigen das viele Schwaben nicht von dieser Welt
> sind ;-)

Ich würde dich doch bitten, dich nur über Themen zu lustig zu machen,=

von denen du was verstehst, z. B. PHP. ;-) Vom Forschungsstand der
experimentellen Parapsychologie verstehst du offenbar nix. Aber wie
gesagt, das ist ein anderes Thema.

F'up2Poster

SCNR,

Alex

On 15 Aug., 09:09, Stefan Braumeister <sbra... [at] gmx.net> wrote:
> juni.joz... [at] web.de schrieb:
>
>
>
>
>
> > On 15 Aug., 06:03, juni.joz... [at] web.de wrote:
> >> On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
>
> Ich hab jetzt länger nichts mehr mit PHP unter nem 32Bit OS gemacht,
> aber es würde mich wundern, wenn eine aktuelle PHP Version das von dir
> beschriebene Problem hat.
> Ist es möglich, dass du noch eine sehr alte PHP Version verwendest.
>
> Gruß Stefan
>
>

Die PHP-Version ist 4.2.2-17.
Ist zwar nicht die brandaktuelle, aber auch nicht uralt.

Gruß Jozsef

On 15 Aug., 09:38, Joe Scylla <joe.scy... [at] gmail.com> wrote:
> juni.joz... [at] web.de wrote:
> > Ich hab den Fehler eingegrenzt.
>
> > Es liegt offensichtlich an der Dateigröße.
> > Der Fehler tritt nur bei Dateien auf, die grüßer als 2GB sind.
>
> > Gibt es eine andere Möglichkeit außer mit filectime() oder stat()
> > an das Dateidatum zu kommen?
>
> Eventuell trifft dieser Bug zu:http://bugs.php.net/bug.php?id=3D27792
>
> <quote>
> Note: Because PHP's integer type is signed and many platforms use 32bit
> integers, filesize() may return unexpected results for files which are
> larger than 2GB. For files between 2GB and 4GB in size this can usually
> be overcome by using sprintf("%u", filesize($file)).
> </quote>
>
> Joe


Ja, anscheinend ist genau das mein Problem.

Gruß Jozsef

juni.jozsef [at] web.de schrieb:
> On 15 Aug., 09:09, Stefan Braumeister <sbra... [at] gmx.net> wrote:
>> juni.joz... [at] web.de schrieb:
>>
>>
>>
>>
>>
>>> On 15 Aug., 06:03, juni.joz... [at] web.de wrote:
>>>> On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
>> Ich hab jetzt länger nichts mehr mit PHP unter nem 32Bit OS gemacht,
>> aber es würde mich wundern, wenn eine aktuelle PHP Version das von dir
>> beschriebene Problem hat.
>> Ist es möglich, dass du noch eine sehr alte PHP Version verwendest.
>>
>> Gruß Stefan
>>
>>
>
> Die PHP-Version ist 4.2.2-17.
> Ist zwar nicht die brandaktuelle, aber auch nicht uralt.

Die ist 5 Jahre alt.

Melde dich nochmal, nachdem du das Ganze auf einer aktuellen PHP Version
getestet hast.


Gruß Stefan
>
> Gruß Jozsef
>

juni.jozsef [at] web.de schrieb:
> Die PHP-Version ist 4.2.2-17.
> Ist zwar nicht die brandaktuelle, aber auch nicht uralt.

Du findest Frühling 2002 im Zeitalter der schnelllebigen IT nicht uralt?


MfG
Sebastian Wessel

--
Individualitaet ist ok, solange wir es alle zusammen tun
Major Frankling Burns (M*A*S*H)

On 16 Aug., 09:03, Stefan Braumeister <sbra... [at] gmx.net> wrote:
> juni.joz... [at] web.de schrieb:
>
>
>
>
>
> > On 15 Aug., 09:09, Stefan Braumeister <sbra... [at] gmx.net> wrote:
> >> juni.joz... [at] web.de schrieb:
>
> >>> On 15 Aug., 06:03, juni.joz... [at] web.de wrote:
> >>>> On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
> >> Ich hab jetzt länger nichts mehr mit PHP unter nem 32Bit OS gemacht,
> >> aber es würde mich wundern, wenn eine aktuelle PHP Version das von d=
ir
> >> beschriebene Problem hat.
> >> Ist es möglich, dass du noch eine sehr alte PHP Version verwendest.
>
> >> Gruß Stefan
>
> > Die PHP-Version ist 4.2.2-17.
> > Ist zwar nicht die brandaktuelle, aber auch nicht uralt.
>
> Die ist 5 Jahre alt.
>
> Melde dich nochmal, nachdem du das Ganze auf einer aktuellen PHP Version
> getestet hast.
>
> Gruß Stefan
>
>
>
>
>
> > Gruß Jozsef- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Bisher hat die benutzte PHP-Version gute Dienste geleistet.

Wenn du mir garantieren kannst, dass alle Scripte weiterhin
einwandfrei funktionieren, dann werde ich gerne mal die Arbeit
auf mich nehmen und die 5er Version installieren.

Gruß Jozsef

On 16 Aug., 09:03, Sebastian Wessel <sir-pr... [at] gmx.de> wrote:
> juni.joz... [at] web.de schrieb:
>
> > Die PHP-Version ist 4.2.2-17.
> > Ist zwar nicht die brandaktuelle, aber auch nicht uralt.
>
> Du findest Frühling 2002 im Zeitalter der schnelllebigen IT nicht uralt?
>
> MfG
> Sebastian Wessel
>

Nö,

4=2E2.xx
4=2E3.xx
4=2E4.xx

5=2Ex.xx


Lediglich eine Versionsnummer vor der aktuellen.

Wir haben hir noch alte DOS- Programme unter Win XP Prof im
Dos-Fenster am laufen, die wir auf keinen Fall durch neue
Mausklick-Programme ersetzen werden.

Und Alt ist doch nicht zwingend mit Schlecht gleichbedeutend. ;-)

Gruß Jozsef

juni.jozsef [at] web.de schrieb:
> On 16 Aug., 09:03, Sebastian Wessel <sir-pr... [at] gmx.de> wrote:
>> juni.joz... [at] web.de schrieb:
>>
>>> Die PHP-Version ist 4.2.2-17.
>>> Ist zwar nicht die brandaktuelle, aber auch nicht uralt.
>> Du findest Frühling 2002 im Zeitalter der schnelllebigen IT nicht uralt?
>>
>> MfG
>> Sebastian Wessel
>>
>
> Nö,
>
> 4.2.xx
> 4.3.xx
> 4.4.xx
>
> 5.x.xx
>
>
> Lediglich eine Versionsnummer vor der aktuellen.
>
> Wir haben hir noch alte DOS- Programme unter Win XP Prof im
> Dos-Fenster am laufen, die wir auf keinen Fall durch neue
> Mausklick-Programme ersetzen werden.
>
> Und Alt ist doch nicht zwingend mit Schlecht gleichbedeutend. ;-)

Wenn du die Changelogs seit dieser Zeit einmal durchblätterst und nur
grob überfliegst, was es so an Fehlern und Sicherheitslücken gab/gibt:
Oh doch!

Gruß,
Torsten

juni.jozsef [at] web.de schrieb:
> On 16 Aug., 09:03, Stefan Braumeister <sbra... [at] gmx.net> wrote:
>> juni.joz... [at] web.de schrieb:
>>
>>
>>
>>
>>
>>> On 15 Aug., 09:09, Stefan Braumeister <sbra... [at] gmx.net> wrote:
>>>> juni.joz... [at] web.de schrieb:
>>>>> On 15 Aug., 06:03, juni.joz... [at] web.de wrote:
>>>>>> On 14 Aug., 23:46, Ulf Kadner <dr_lo... [at] gmx.net> wrote:
>>>> Ich hab jetzt länger nichts mehr mit PHP unter nem 32Bit OS gemacht,
>>>> aber es würde mich wundern, wenn eine aktuelle PHP Version das von dir
>>>> beschriebene Problem hat.
>>>> Ist es möglich, dass du noch eine sehr alte PHP Version verwendest.
>>>> Gruß Stefan
>>> Die PHP-Version ist 4.2.2-17.
>>> Ist zwar nicht die brandaktuelle, aber auch nicht uralt.
>> Die ist 5 Jahre alt.
>>
>> Melde dich nochmal, nachdem du das Ganze auf einer aktuellen PHP Version
>> getestet hast.
>>
>> Gruß Stefan
>>
>>
>>
>>
>>
>>> Gruß Jozsef- Zitierten Text ausblenden -
>> - Zitierten Text anzeigen -- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
>
>
> Bisher hat die benutzte PHP-Version gute Dienste geleistet.
>
> Wenn du mir garantieren kannst, dass alle Scripte weiterhin
> einwandfrei funktionieren, dann werde ich gerne mal die Arbeit
> auf mich nehmen und die 5er Version installieren.

Eine aktuelle 4er sollte reichen und da musst du nicht damit rechnen,
dass einige deiner Scripte nicht mehr laufen.

Aber ein upgrade auf die 5 solltest du ins Auge fassen, da der Support
der 4er Serie dieses Jahr ausläuft.

Gruß Stefan


>
> Gruß Jozsef
>

Hi,

juni.jozsef [at] web.de wrote:

> Wir haben hir noch alte DOS- Programme unter Win XP Prof im
> Dos-Fenster am laufen, die wir auf keinen Fall durch neue
> Mausklick-Programme ersetzen werden.

Nicht alles, was hinkt, ist ein Vergleich. Wenn ihr mit diesen
DOS-Programmen nicht ins Netz geht, ist das nicht ansatzweise so
brandgefährlich wie das Hantieren mit einer uralten PHP-Version mit
weltbekannten Sicherheitslücken.

> Und Alt ist doch nicht zwingend mit Schlecht gleichbedeutend. ;-)

Nicht zwingend, nein. Aber der Betrieb einer solchen Uralt-PHP-Version
ist ob der seitdem gefixten Sicherheitslücken m. E. fahrlässig. Ihr
solltet dringend ein Update in Erwägung ziehen.

Grüße,

Alex

On 17 Aug., 02:13, Alexander Schestag <a... [at] schestag.info> wrote:
> Hi,
>
> > Und Alt ist doch nicht zwingend mit Schlecht gleichbedeutend. ;-)
>
> Nicht zwingend, nein. Aber der Betrieb einer solchen Uralt-PHP-Version
> ist ob der seitdem gefixten Sicherheitslücken m. E. fahrlässig. Ihr
> solltet dringend ein Update in Erwägung ziehen.
>
> Grüße,
>
> Alex


Es handelt sich um einen Linux Server in einem Internen Netzwerk.
Er dient in einem kleinen Unternehmen (15 Mitarbeiter) als Webwerver
und stellt den gesamten Schriftverkehr als PDF-Dokumente zur
Verfügung.
"Nebenher" laufen halt diverse kleinere Scripte unter PHP drauf.

Die Angestellten sind zu 95% "reifere" Damen (>=3D50).

Da halten sich meine SIcherheitsbedenken in Grenzen.


Mein Problem liesse sich ja auch mit einem Shell script lösen, nur
kenne ich mich da mit der Syntax (noch) garnicht aus.

Ich möchte lediglich folgendes erreichen:
In auswählbaren Verzeichnissen sollen alle Dateien, die älter sind als
30 Tage gelöscht werden, es sei denn, sie wurden jeweils am 1. eines
Monats erstellt.

Hat jemand nen anderen Ansatz?

Gruß J=F3zsef

juni.jozsef [at] web.de schrieb:
> On 17 Aug., 02:13, Alexander Schestag <a... [at] schestag.info> wrote:
>> Hi,
>>
>>> Und Alt ist doch nicht zwingend mit Schlecht gleichbedeutend. ;-)
>> Nicht zwingend, nein. Aber der Betrieb einer solchen Uralt-PHP-Version
>> ist ob der seitdem gefixten Sicherheitslücken m. E. fahrlässig. Ihr
>> solltet dringend ein Update in Erwägung ziehen.
>>
>> Grüße,
>>
>> Alex
>
>
> Es handelt sich um einen Linux Server in einem Internen Netzwerk.
> Er dient in einem kleinen Unternehmen (15 Mitarbeiter) als Webwerver
> und stellt den gesamten Schriftverkehr als PDF-Dokumente zur
> Verfügung.
> "Nebenher" laufen halt diverse kleinere Scripte unter PHP drauf.
>
> Die Angestellten sind zu 95% "reifere" Damen (>=50).
>
> Da halten sich meine SIcherheitsbedenken in Grenzen.

Meine Sicherheitsbedenken erhöhen sich gerade, woher kommen denn in so
einem Laden einzelne Dateien >2GB her?

>
>
> Mein Problem liesse sich ja auch mit einem Shell script lösen, nur
> kenne ich mich da mit der Syntax (noch) garnicht aus.
>
> Ich möchte lediglich folgendes erreichen:
> In auswählbaren Verzeichnissen sollen alle Dateien, die älter sind als
> 30 Tage gelöscht werden, es sei denn, sie wurden jeweils am 1. eines
> Monats erstellt.
>
> Hat jemand nen anderen Ansatz?



Ein Perl scriptchen vai cron gestartet, in etwa:

[at] dirs = (
"/pfad1/",
"/pfad2/",
);

foreach my $dir( [at] dirs)
{
opendir ...
readdir ...
}

Wenn du auch in Unterverzechnissen suchen musst, dann musst du das halt
in eine rekursive function einbauene.
Dann guckst du zum einen ob der Zeitstempel der Datei älter als 30 Tage
ist, der Einfachheit halber kannste du ja einfach Unixzeit nutzen, bei
jeder Datei prüfst du ob der Tag nicht gleich 1 ist, dafür gibts ja ne
einfache Perlfunction, die dir Tag, Monat , Jahr etc. zurückliefert.

Gruß Stefan


>
> Gruß József
>
>

On 17 Aug., 23:50, Stefan Braumeister <sbra... [at] gmx.net> wrote:
> juni.joz... [at] web.de schrieb:
>
>
>
> Meine Sicherheitsbedenken erhöhen sich gerade, woher kommen denn in so
> einem Laden einzelne Dateien >2GB her?
>
>

Es handelt sich um Datensicherungen.

Das sind gesammelte Datenbestände die von der Firma für unsere Kunden
seit
ca. 15 Jahren. generiert wurden. Insgsamt fallen dann 3 Dateien an:
1* ca 3Gb, 1* ca. 1Gb und 1* ca. 600 Mb - täglich.

>
> Ein Perl scriptchen vai cron gestartet, in etwa:
>
> ... ... ...
>
>
Dann nehm ich doch lieber gleich die Shell ohne Perl.

Trotzdem Danke.

Hallo, juni.jozsef,

Du (juni.jozsef) meintest am 17.08.07:

>> Meine Sicherheitsbedenken erhöhen sich gerade, woher kommen denn in
>> so einem Laden einzelne Dateien >2GB her?

> Es handelt sich um Datensicherungen.

> Das sind gesammelte Datenbestände die von der Firma für unsere Kunden
> seit
> ca. 15 Jahren. generiert wurden. Insgsamt fallen dann 3 Dateien an:
> 1* ca 3Gb, 1* ca. 1Gb und 1* ca. 600 Mb - täglich.

Hat nix mit PHP zu tun - habt ihr euch mal mit "rsnapshot" beschäftigt?

Wenn ihr auf eine Platte sichern könnt, deren Dateisystem "hard links"
erlaubt, kommt ihr zu geringeren Datenmengen - mit Hilfe von "rsync"
werden tatsächlich nur die Änderungen verarbeitet, der Rest wird mit den
früheren Dateien verlinkt.

Ein kleinerer Provider in der Nachbarschaft sichert auf diese Weise
inzwischen stündlich.

Viele Gruesse!
Helmut

juni.jozsef [at] web.de wrote:
> On 17 Aug., 02:13, Alexander Schestag <a... [at] schestag.info> wrote:

>> Nicht zwingend, nein. Aber der Betrieb einer solchen Uralt-PHP-Version=

>> ist ob der seitdem gefixten Sicherheitslücken m. E. fahrlässig. Ih=
r
>> solltet dringend ein Update in Erwägung ziehen.

> Es handelt sich um einen Linux Server in einem Internen Netzwerk.

Ok, da kann man es durchgehen lassen, insofern das interne Netzwerk
*wirklich* dicht ist. ;-)

Grüße,

Alex