14
Dateizugriff extrem langsam
Hallo zusammen,
wir arbeiten hier mit ca. 25 Clients (W2K und XP Prof) in einer Domäne (Win2003). Seit wir unsere Server vor ca. 3 Wochen von W2K auf 2003 aufgerüstet haben, laufen unsere Clients nicht mehr ganz rund...
Aufgefallen ist uns das Problem das erste mal, als versucht wurde Dateien, die auf dem Server liegen zu öffnen - was eine halbe Ewigkeit gedauert hat.
Inzwischen sind auch Zugriffe auf lokale Dateien sehr langsam. Nur mal als Beispiel: Um das Kontextmenü einer Datei, die auf C: liegt aufzurufen vergehen schon mal 10-20 Sekunden. Natürlich ist das auch der Fall, wenn man das Kontextmenü einer Datei auf dem Server aufruft.
Das gleiche passiert auch, wenn man sich mit einem lokalen Benutzer am PC anmeldet (z.B. lokaler Admin mit dem Netzwerkstecker gezogen, keine Richtlinien, kein Anmeldeskript).
Leider kann ich nicht sagen, ob das Problem mit den lokalen Dateien von Anfang an da war, oder ob es sich eingeschlichen hat. Der Netzwerkzugriff war auf jeden Fall von Anfang an langsam.
Werden nun die gleichen Dateien nicht über den Windows Explorer sondern über den Total Commander oder aus der entsprechenden Applikation geöffnet gibt es keinerlei Probleme - soll heißen: die Datei öffent sich SOFORT (ist nur sehr lästig z.B. erst Word zu öffnen um dann die Datei zu suchen).
Insofern kann man das Problem ziemlich präzise auf den Windows Explorer einschränken. Wenn man über Start auf Programme hovert, vergehen auch ca. 10 Sek. bis der Ordner aufgeht (nun gut - läuft ja vermutlich auch auf Win Explorer Basis).
Ordner hingegen werden sofort geöffnet und deren Kontextmenüs SOFORT angezeigt , egal ob lokal oder im Netz.
Der Taskmanager zeigt beim Aufruf des Kontextmenüs von Dateien keinerlei Aktivität an (Leerlauf 99%)
Das beschriebene Phänomen tritt allerdings NUR bei XP Clients auf - W2K scheint verschont geblieben zu sein.
Letzte Woche haben wir auch einige neue Clients (XP) der Domäne hinzugefügt, bei denen alles in Ordnung zu sein scheint. Rechtsklick, und siehe da das Kontextmenü kommt sofort.
Der Updatestand ist bei allen Clients gleich und aktuell: W2K SP4, XP SP2 (automatische Updates) - auch bei denen, die später in die Domäne kamen. Also liegts nicht an den Patches.
Virenscanner: Avast (managed) ist aktuell (haben wir auch früher schon verwendet - keine Probleme)
Sonst sind auch keine außergewöhnlichen Applikationen drauf:
Office 2003, Acrobat Reader, etc. das übliche halt...
Hat irgendwer eine Idee, was hier los ist? Wäre für jede Lösung dankbar.
wir arbeiten hier mit ca. 25 Clients (W2K und XP Prof) in einer Domäne (Win2003). Seit wir unsere Server vor ca. 3 Wochen von W2K auf 2003 aufgerüstet haben, laufen unsere Clients nicht mehr ganz rund...
Aufgefallen ist uns das Problem das erste mal, als versucht wurde Dateien, die auf dem Server liegen zu öffnen - was eine halbe Ewigkeit gedauert hat.
Inzwischen sind auch Zugriffe auf lokale Dateien sehr langsam. Nur mal als Beispiel: Um das Kontextmenü einer Datei, die auf C: liegt aufzurufen vergehen schon mal 10-20 Sekunden. Natürlich ist das auch der Fall, wenn man das Kontextmenü einer Datei auf dem Server aufruft.
Das gleiche passiert auch, wenn man sich mit einem lokalen Benutzer am PC anmeldet (z.B. lokaler Admin mit dem Netzwerkstecker gezogen, keine Richtlinien, kein Anmeldeskript).
Leider kann ich nicht sagen, ob das Problem mit den lokalen Dateien von Anfang an da war, oder ob es sich eingeschlichen hat. Der Netzwerkzugriff war auf jeden Fall von Anfang an langsam.
Werden nun die gleichen Dateien nicht über den Windows Explorer sondern über den Total Commander oder aus der entsprechenden Applikation geöffnet gibt es keinerlei Probleme - soll heißen: die Datei öffent sich SOFORT (ist nur sehr lästig z.B. erst Word zu öffnen um dann die Datei zu suchen).
Insofern kann man das Problem ziemlich präzise auf den Windows Explorer einschränken. Wenn man über Start auf Programme hovert, vergehen auch ca. 10 Sek. bis der Ordner aufgeht (nun gut - läuft ja vermutlich auch auf Win Explorer Basis).
Ordner hingegen werden sofort geöffnet und deren Kontextmenüs SOFORT angezeigt , egal ob lokal oder im Netz.
Der Taskmanager zeigt beim Aufruf des Kontextmenüs von Dateien keinerlei Aktivität an (Leerlauf 99%)
Das beschriebene Phänomen tritt allerdings NUR bei XP Clients auf - W2K scheint verschont geblieben zu sein.
Letzte Woche haben wir auch einige neue Clients (XP) der Domäne hinzugefügt, bei denen alles in Ordnung zu sein scheint. Rechtsklick, und siehe da das Kontextmenü kommt sofort.
Der Updatestand ist bei allen Clients gleich und aktuell: W2K SP4, XP SP2 (automatische Updates) - auch bei denen, die später in die Domäne kamen. Also liegts nicht an den Patches.
Virenscanner: Avast (managed) ist aktuell (haben wir auch früher schon verwendet - keine Probleme)
Sonst sind auch keine außergewöhnlichen Applikationen drauf:
Office 2003, Acrobat Reader, etc. das übliche halt...
Hat irgendwer eine Idee, was hier los ist? Wäre für jede Lösung dankbar.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 36578
Url: https://administrator.de/contentid/36578
Printed on: April 25, 2024 at 07:04 o'clock
14 Comments
Latest comment
Hi,
haben die "älteren" rechner die geleichen RAM-Bausteine drinne wie die neu aufgesetzten. Möglicherweiße stimmt mit den Bausteinen irgendetwas nicht bzw. zu wenig Arbeitsspeichr.
mfg
derby
haben die "älteren" rechner die geleichen RAM-Bausteine drinne wie die neu aufgesetzten. Möglicherweiße stimmt mit den Bausteinen irgendetwas nicht bzw. zu wenig Arbeitsspeichr.
mfg
derby
Es sind Rechner unterschiedlichster Bauart...
RAM von 256MB bis 2GB... ich kann mir nicht vorstellen, dass bei 25 verschiedenen Rechnern das gleiche Problem deswegen auftaucht.
RAM von 256MB bis 2GB... ich kann mir nicht vorstellen, dass bei 25 verschiedenen Rechnern das gleiche Problem deswegen auftaucht.
Hi,
ist vielleicht eine Netzwerkfreigabe, die auf den Clients gemappt ist, auf dem Server nicht mehr vorhanden? Wir hatten so ein ähnliches Problem. Ansonsten könnte den Server auch die Windows-Firewall oder möglicherweise auch die Schattenkopien bremsen.
Jetzt noch eine Sache die zugegeben sehr weit hergeholt klingt, beim Upgrade auf W2K3 wurde vermutlich auch die Domäne migriert. Wenn nin neue Clients gut laufen, könnte man mal versuchen einen bestehenden "alten" Computer aus der Domäne zu löschen und danach wieder neu hinzufügen(Pferde und Apotheke!!!).
Gruß Bolle97
ist vielleicht eine Netzwerkfreigabe, die auf den Clients gemappt ist, auf dem Server nicht mehr vorhanden? Wir hatten so ein ähnliches Problem. Ansonsten könnte den Server auch die Windows-Firewall oder möglicherweise auch die Schattenkopien bremsen.
Jetzt noch eine Sache die zugegeben sehr weit hergeholt klingt, beim Upgrade auf W2K3 wurde vermutlich auch die Domäne migriert. Wenn nin neue Clients gut laufen, könnte man mal versuchen einen bestehenden "alten" Computer aus der Domäne zu löschen und danach wieder neu hinzufügen(Pferde und Apotheke!!!).
Gruß Bolle97
Hi,
also die Windows Firewall ist auf allen Clients per Gruppenrichtlinie deaktiviert. Auf dem Server ebenfalls.
Es gibt auch keine "alten" gemappten Netzwerkfreigaben, die nicht gefunden werden, da wir die Laufwerke, die überhaupt standartmäßig gemappt werden gleich benannt haben (inkl. Laufwerksbuchstaben). Mal abgesehen davon würde es doch diesbezüglich eine Meldung auf dem Client geben? Nach meinen Erfahrungen würde eine nicht gefundene Freigabe auch nur den Systemstart etwas verzögern und nicht danach die Arbeit mit dem Windows Explorer, oder?
Da es eben genau nicht so ist, dass die Domäne migriert wurde (weil vorher interne und externe Domäne gleich benannt waren - was bei uns zu massiven Problemen geführt hat...), mussten wir die Clients sowieso neu der Domäne hinzufügen - was auch noch gegen die "gemappten Freigaben" sprechen würde. Wir haben im Grunde NUR die Daten migriert und alles andere neu aufgesetzt. Die Server sind brandneu...
Der einzige Unterschied zwischen den neuen und alten Clients ist, dass die "Alten" sofort nach dem Serverumzug hinzugefügt wurden und die "Neuen" ca. 3 Wochen später...
und wie ich ja auch beschrieben habe tauchen die Probleme ja auch auf, wenn man sich lokal anmeldet.
Grüße apache
also die Windows Firewall ist auf allen Clients per Gruppenrichtlinie deaktiviert. Auf dem Server ebenfalls.
Es gibt auch keine "alten" gemappten Netzwerkfreigaben, die nicht gefunden werden, da wir die Laufwerke, die überhaupt standartmäßig gemappt werden gleich benannt haben (inkl. Laufwerksbuchstaben). Mal abgesehen davon würde es doch diesbezüglich eine Meldung auf dem Client geben? Nach meinen Erfahrungen würde eine nicht gefundene Freigabe auch nur den Systemstart etwas verzögern und nicht danach die Arbeit mit dem Windows Explorer, oder?
Da es eben genau nicht so ist, dass die Domäne migriert wurde (weil vorher interne und externe Domäne gleich benannt waren - was bei uns zu massiven Problemen geführt hat...), mussten wir die Clients sowieso neu der Domäne hinzufügen - was auch noch gegen die "gemappten Freigaben" sprechen würde. Wir haben im Grunde NUR die Daten migriert und alles andere neu aufgesetzt. Die Server sind brandneu...
Der einzige Unterschied zwischen den neuen und alten Clients ist, dass die "Alten" sofort nach dem Serverumzug hinzugefügt wurden und die "Neuen" ca. 3 Wochen später...
und wie ich ja auch beschrieben habe tauchen die Probleme ja auch auf, wenn man sich lokal anmeldet.
Grüße apache
Hi,
ja, klingt alles sehr komisch.
Läuft auf den Servern DNS oder DHCP? Wenn DNS, stimmen die Clienteinstellungen bezüglich der DNS-Server noch? Die Server haben ja bestimmt andere IP-Adressen bekommen.
Gruß Bolle97
ja, klingt alles sehr komisch.
Läuft auf den Servern DNS oder DHCP? Wenn DNS, stimmen die Clienteinstellungen bezüglich der DNS-Server noch? Die Server haben ja bestimmt andere IP-Adressen bekommen.
Gruß Bolle97
Als DNS-Server war bei den Clients noch nie ein bestimmter Server eingetragen (im Grunde also Grundeinstellung). Die TCP/IP Einstellungen werden automatisch vergeben. DHCP aktiv.
Gruß apache
Gruß apache
Kleines Update:
heute Morgen habe ich mal alle Shell Extensions für das Kontext Menü von Third Party Anbietern deaktiviert, was leider auch zu keinem Erfolg geführt hat.
Dabei ist mir aber aufgefallen, dass ein Rechtsklick auf .exe Dateien sofort das Kontextmenü aufruft, was bei keiner anderen Dateiart der Fall ist.
Nur mal so...
Gruß apache
heute Morgen habe ich mal alle Shell Extensions für das Kontext Menü von Third Party Anbietern deaktiviert, was leider auch zu keinem Erfolg geführt hat.
Dabei ist mir aber aufgefallen, dass ein Rechtsklick auf .exe Dateien sofort das Kontextmenü aufruft, was bei keiner anderen Dateiart der Fall ist.
Nur mal so...
Gruß apache
Hallo,
wie ich schon vorher geschrieben habe, haben wir nichts ungewöhnliches installiert.
Clients:
normale Office SW (Arobat Reader, Office 2003, etc.), Avast! Antivirus (managed), Imagenation, und eine ERP SW
auf manchen Clients ist noch ProE (aber das ist eher die Ausnahme)
Server (es sind mehrere, die sich die Apps teilen):
Exchange, 2 x Oracle DBs (läuft je auf 'nem extra Server), Imagenation LM, ProE LM
aber ALLE Applicationen hatten wir vorher auch auf unseren Servern OHNE Probs...
Gruß apache
wie ich schon vorher geschrieben habe, haben wir nichts ungewöhnliches installiert.
Clients:
normale Office SW (Arobat Reader, Office 2003, etc.), Avast! Antivirus (managed), Imagenation, und eine ERP SW
auf manchen Clients ist noch ProE (aber das ist eher die Ausnahme)
Server (es sind mehrere, die sich die Apps teilen):
Exchange, 2 x Oracle DBs (läuft je auf 'nem extra Server), Imagenation LM, ProE LM
aber ALLE Applicationen hatten wir vorher auch auf unseren Servern OHNE Probs...
Gruß apache
Auch ich möchte zur Lösung beitragen da ich das gleiche Problem habe. (nur Privat auf meinem Rechner)
Folgendes kann ich dazu beitragen.
Ich habe das Problem erst seit ich bei meinem Rechner von IDE auf SATA umgestiegen bin. Auschließen kann ich aber auch das es an den Festplatten liegt, da ich 2 Festplatte benutze und das Problem bei beiden Laufwerken auftritt.
Meines erachtens Liegt das Problem nicht an Updates oder ähnlichem weil ich meinen Computer nach der Neuinstallation sofort auf den aktuellsten Stand gebracht habe und das Problem zu dieser Zeit noch nicht vorhanden war.
Auch das es irgendwelche Einträge im Kontextmenü sind denke ich nicht, da ich bereits in der Registry unter HKEY_CLASSES_ROOT\*\ShellEx mein Kontextmenü von sämtlichen Sachen von Drittanbietern befreit habe.
Kurz noch eine Beschreibung wie sich das Problem bei mir äußert:
Wie schon oben erwähnt dauert es ca. 5 Sekunden bis sich mein Kontextmenü öffnet. Hinzukommt das zb. beim Doppelklick auf mp3s es auch ca. 5 Sekunden dauert bis das Programm beginnt die Datei zu lesen. (Also nicht nur bei mp3s sondern auch bei .txt .cfg usw.)
Meinen Rechner hatte deswegen auch schon neuinstalliert. Das Problem tratt nach der Neuinstallation wieder auf. An welchem Programm oder durch was dieses Problem verursacht wurde konnte ich aber nicht feststellen.
Virenbefall ist Aufgrund dessen das die Systeme neuinstalliert wurden auch nicht das Problem.
Folgendes kann ich dazu beitragen.
Ich habe das Problem erst seit ich bei meinem Rechner von IDE auf SATA umgestiegen bin. Auschließen kann ich aber auch das es an den Festplatten liegt, da ich 2 Festplatte benutze und das Problem bei beiden Laufwerken auftritt.
Meines erachtens Liegt das Problem nicht an Updates oder ähnlichem weil ich meinen Computer nach der Neuinstallation sofort auf den aktuellsten Stand gebracht habe und das Problem zu dieser Zeit noch nicht vorhanden war.
Auch das es irgendwelche Einträge im Kontextmenü sind denke ich nicht, da ich bereits in der Registry unter HKEY_CLASSES_ROOT\*\ShellEx mein Kontextmenü von sämtlichen Sachen von Drittanbietern befreit habe.
Kurz noch eine Beschreibung wie sich das Problem bei mir äußert:
Wie schon oben erwähnt dauert es ca. 5 Sekunden bis sich mein Kontextmenü öffnet. Hinzukommt das zb. beim Doppelklick auf mp3s es auch ca. 5 Sekunden dauert bis das Programm beginnt die Datei zu lesen. (Also nicht nur bei mp3s sondern auch bei .txt .cfg usw.)
Meinen Rechner hatte deswegen auch schon neuinstalliert. Das Problem tratt nach der Neuinstallation wieder auf. An welchem Programm oder durch was dieses Problem verursacht wurde konnte ich aber nicht feststellen.
Virenbefall ist Aufgrund dessen das die Systeme neuinstalliert wurden auch nicht das Problem.
Hi, sorry - wir hatten am Di. hier in der Schweiz Feiertag, deshalb ist Mo. auch nix gelaufen... 
@mp:
Client-Seitig ist's nicht viel:
- Oracle Universal Installer
- OraHome81
- Net8 Client 8.1.7.0.0
- Oracle 8i ODBC Driver 8.1.7.8.0b
... kann mir aber beim besten Willen nicht vorstellen, dass es an diesen Komponenten liegt - hatten wir auch schon früher drauf.
Wie gesagt: ich sehe eher das Problem beim Win-Explorer und/oder seinen Plugins. (s.o.: Datei öffnen über Win Commander -> nicht mal ne Sekunde - über Windows Explorer ca. 15 Sek.)
@m3ss3r:
Das ist erstaunlich - hier wäre es mal interessant gewesen nach welchem Update/Patch genau das Phänomen aufgetreten ist?
Was ich inzwischen feststellen musste war auch, dass ein Windows 2000 Rechner mit 512MB RAM in die Knie gegangen ist wegen diesem Avast! Antiviren-Scanner, der seinen Scan "im Hintergrund" hätte laufen lassen sollen, dabei aber 99% der Systemrecourcen verbraucht hat.
Allerdings werden durch die Deinstallation von Avast! die Dateizugriffe auch nicht schneller... liegt also auch nicht daran!
Gruß apache
@mp:
Client-Seitig ist's nicht viel:
- Oracle Universal Installer
- OraHome81
- Net8 Client 8.1.7.0.0
- Oracle 8i ODBC Driver 8.1.7.8.0b
... kann mir aber beim besten Willen nicht vorstellen, dass es an diesen Komponenten liegt - hatten wir auch schon früher drauf.
Wie gesagt: ich sehe eher das Problem beim Win-Explorer und/oder seinen Plugins. (s.o.: Datei öffnen über Win Commander -> nicht mal ne Sekunde - über Windows Explorer ca. 15 Sek.)
@m3ss3r:
Meinen Rechner hatte deswegen auch schon neuinstalliert. Das Problem tratt nach der Neuinstallation wieder auf. An welchem Programm oder durch was dieses Problem verursacht wurde konnte ich aber nicht feststellen.
Das ist erstaunlich - hier wäre es mal interessant gewesen nach welchem Update/Patch genau das Phänomen aufgetreten ist?
Was ich inzwischen feststellen musste war auch, dass ein Windows 2000 Rechner mit 512MB RAM in die Knie gegangen ist wegen diesem Avast! Antiviren-Scanner, der seinen Scan "im Hintergrund" hätte laufen lassen sollen, dabei aber 99% der Systemrecourcen verbraucht hat.
Allerdings werden durch die Deinstallation von Avast! die Dateizugriffe auch nicht schneller... liegt also auch nicht daran!
Gruß apache
Ich kann mir nicht vorstellen, dass es ein
bestimmtes Update oder ein bestimmer Patch
ist.
Wir haben im Unternehmen einen WSUS-Server
der alle Clients auf den gleichen
Updatestand bringt. Das Problem tritt aber
nur 2 mal auf.
bestimmtes Update oder ein bestimmer Patch
ist.
Wir haben im Unternehmen einen WSUS-Server
der alle Clients auf den gleichen
Updatestand bringt. Das Problem tritt aber
nur 2 mal auf.
Tja, nun sind wir so schlau wie vorher...
Aber ne Lösung hätte ich schon ganz gerne... zumal das echt zu Tode nervt!
Ich habe jetzt echt schon fast alles versucht... alles unnötige vom Rechner geschmissen, auf Viren untersucht, etc. pp. - keine Änderung.
Hallo zusammen,
nach langer Suche und intensivem Kontakt mit MS haben wir das Problem gelöst. Es war ein Registry Eintrag des Programms Imagenation View von Spicer. Da dieses Programm mit einem License-Manager läuft und wir noch keine neue Lizenz (MAC Adresse) für den neuen Server hatten, hatten wir die neuen und alten Server ca. 2 Wochen im Parallelbertieb. Auf einigen Clients wurde die Software extra noch für den alten Server konfiguriert, weil dieser sich ja nicht mehr in der Domäne befand. Als dann die neue Lizenz eintraf wurde das dann entsprechend in der .ini der SW geändert. Laut SW lieferant wäre das auch ausreichend gewesen. Leider hatte sich aber doch ein Schlüssel der SW in der Registry eingeschlichen, der sich auch durch Deinstallation nicht entfernen lies.
Das erklährt auch, warum neue Clients inder Domäne nicht betroffen waren.
Das Problem ist somit gelöst.
Ach so der Hauptschlüssel war:
HKEY_CLASSES_ROOT\Applications\ImageReady.exe (und alle Unterschlüssel)
Grüße apache
nach langer Suche und intensivem Kontakt mit MS haben wir das Problem gelöst. Es war ein Registry Eintrag des Programms Imagenation View von Spicer. Da dieses Programm mit einem License-Manager läuft und wir noch keine neue Lizenz (MAC Adresse) für den neuen Server hatten, hatten wir die neuen und alten Server ca. 2 Wochen im Parallelbertieb. Auf einigen Clients wurde die Software extra noch für den alten Server konfiguriert, weil dieser sich ja nicht mehr in der Domäne befand. Als dann die neue Lizenz eintraf wurde das dann entsprechend in der .ini der SW geändert. Laut SW lieferant wäre das auch ausreichend gewesen. Leider hatte sich aber doch ein Schlüssel der SW in der Registry eingeschlichen, der sich auch durch Deinstallation nicht entfernen lies.
Das erklährt auch, warum neue Clients inder Domäne nicht betroffen waren.
Das Problem ist somit gelöst.
Ach so der Hauptschlüssel war:
HKEY_CLASSES_ROOT\Applications\ImageReady.exe (und alle Unterschlüssel)
Grüße apache
Hallo zusammen,
wir hatten exakt das selbe Problem (unter Windows XP Prof.):
- Zugriff auf lokale Dateien und Dateien im Netzwerk (auch Kontextmenüs) stark verzögert
- seltsamerweise tritt diese Verzögerung nicht bei exe-Dateien auf
Aus der Problemlösung von apache0815 haben wir geschlussfolgert, dass es eine
lizenztechnische Ursache haben muss. Als wir dann alle Einträge von Softwareprodukten,
die wir erst nach Installation aktiviert haben, gelöscht hatten, war das Problem behoben.
In unserem Fall waren das
- Adobe Acrobat 8
- Cool Edit 2.0 Pro
- ACDSee
Wahrscheinlich hätte die Löschung des ACDSee-Eintrags ausgereicht, da wir hier eine
noch nicht aktivierte Lizenz verwendeten.
FAZIT:
Löschen der Registry-Schlüssel nicht korrekt lizensierter/aktivierter Software im Pfad
"HKEY_CLASSES_ROOT\Applications" löst das Problem mit den verlangsamten Dateizugriffen.
wir hatten exakt das selbe Problem (unter Windows XP Prof.):
- Zugriff auf lokale Dateien und Dateien im Netzwerk (auch Kontextmenüs) stark verzögert
- seltsamerweise tritt diese Verzögerung nicht bei exe-Dateien auf
Aus der Problemlösung von apache0815 haben wir geschlussfolgert, dass es eine
lizenztechnische Ursache haben muss. Als wir dann alle Einträge von Softwareprodukten,
die wir erst nach Installation aktiviert haben, gelöscht hatten, war das Problem behoben.
In unserem Fall waren das
- Adobe Acrobat 8
- Cool Edit 2.0 Pro
- ACDSee
Wahrscheinlich hätte die Löschung des ACDSee-Eintrags ausgereicht, da wir hier eine
noch nicht aktivierte Lizenz verwendeten.
FAZIT:
Löschen der Registry-Schlüssel nicht korrekt lizensierter/aktivierter Software im Pfad
"HKEY_CLASSES_ROOT\Applications" löst das Problem mit den verlangsamten Dateizugriffen.
Eintrag wurde versehentlich doppelt hinzugefügt.
...
...
EOF!
...
...
EOF!
