Hallo,

bei uns tritt ein extrem merkwürdiges Problem auf, dieses soll nachfolgend beschrieben werden:

Wir haben eine cmd-Datei auf dem Server liegen, soweit kein Problem, die Anwender können darauf ausnahmslos zugreifen. Die cmd-Datei liest eine andere Textdatei aus und schreibt den Zeileninhalt in eine temporäre Datei. Die Textdatei ist ebenfalls bei allen vorhanden, liegt unter dem gleichen Pfad und ist bei allen Anwendern gleich. Beim Auslesen wird nach einer Zeile anhand eines spezifischen Strings (kommt einmalig vor!) gesucht. Eben genau diese Zeile soll in die temporäre Datei geschrieben werden. Das Problem: Bei einigen funktioniert es, bei anderen ist die erstellte Datei leer, woran kann dies liegen? Wir haben bisher keine Gemeinsamenkeiten bei den betroffenen Anwendern gefunden, außer, dass es sich nur um deutsche Anwender zu handeln scheint.

Hier die entsprechende Zeile aus der cmd-Datei:

Code :

1	echo .|Type "%Allusersprofile%\Application Data\Restpfad\Dateiname"|find "Suchstring" > %Temp%\tempdatei.txt

Hi.

Zitat von HonniCilest

Wir haben eine cmd-Datei auf dem Server liegen, soweit kein Problem, die Anwender können darauf ausnahmslos zugreifen. Die cmd-Datei liest eine andere Textdatei aus und schreibt den Zeileninhalt in eine temporäre Datei.

Läßt sich das nicht vermeiden?

Zitat von HonniCilest

Die Textdatei ist ebenfalls bei allen vorhanden, liegt unter dem gleichen Pfad und ist bei allen Anwendern gleich. Beim Auslesen wird nach einer Zeile anhand eines spezifischen Strings (kommt einmalig vor!) gesucht.

Wo kommt dieser String her? Ist der konstant?

Zitat von HonniCilest

Eben genau diese Zeile soll in die temporäre Datei geschrieben werden. Das Problem: Bei einigen funktioniert es, bei anderen ist die erstellte Datei leer, woran kann dies liegen?

Mit temp. Dateien kann es alle möglichen Probleme geben. Der Name der Datei ist konstant?

Zugriffsrechte? Geöffnet durch ein anderes Programm?

Zitat von HonniCilest

Wir haben bisher keine Gemeinsamenkeiten bei den betroffenen Anwendern gefunden, außer, dass es sich nur um deutsche Anwender zu handeln scheint.

Hier die entsprechende Zeile aus der cmd-Datei:

Code :

1	echo .|Type "%Allusersprofile%\Application Data\Restpfad\Dateiname"|find "Suchstring" > %Temp%\tempdatei.txt

Warum so kompliziert?

Code :

1	find "suchstring" "%Allusersprofile%\Application Data\Restpfad\Dateiname" > %Temp%\tempdatei.txt

Gruß

Danke für die Antwort. Zu den Fragen...
1. Was soll sich vermeiden lassen?
2. Ja der String ist konstant, es handelt sich um ein Attribut was von Region zu Region unterschiedlichen Inhalt hat. Das Problem tritt aber nicht bei jedem Anwender der Region auf. Mittlerweile hat es auch nicht deutsche Fälle gegeben.
3. Der Name der temporären Datei ist konstant. Sie ist wirklich temporär und wird nach dem Vorgang wieder gelöscht. Wir haben auch überprüft ob diese überhaupt erstellt wird und die Antwort ist ja. Allerdings ist die Datei leer. Daher können Zugriffsrechte oder andere Programme ausgeschlossen werden.
4. Warum so kompliziert weiß ich nicht, ich habe es nicht geschrieben, sehe trotzdem keinen Grund warum es nicht funktionieren sollte. Du hast aber recht, ist schon irgendwo umständlich, wenn man es mit dem anderen vergleicht

Zitat von HonniCilest

Danke für die Antwort. Zu den Fragen...
1. Was soll sich vermeiden lassen?

Die temp. Datei. http://www.codeproject.com/KB/web-se...eSecurity.aspx

Zitat von HonniCilest

2. Ja der String ist konstant, es handelt sich um ein Attribut was von Region zu Region unterschiedlichen Inhalt hat. Das Problem tritt aber nicht bei jedem Anwender der Region auf. Mittlerweile hat es auch nicht deutsche Fälle gegeben.

Zitat von HonniCilest

3. Der Name der temporären Datei ist konstant.

Das ist schlecht. Was ist wenn das Skript noch läuft und ein anderes Programm greift darauf zu usw. Oder das Skript wird doppelt gestartet...

Zitat von HonniCilest

Sie ist wirklich temporär und wird nach dem Vorgang wieder gelöscht. Wir haben auch überprüft ob diese überhaupt erstellt wird und die Antwort ist ja. Allerdings ist die Datei leer.

Vermutlich wird der String in der Datei einfach nicht gefunden...

Wird denn die Datei in der gesucht wird verändert?

Gruß

Das ist schlecht. Was ist wenn das Skript noch läuft und ein anderes Programm greift darauf zu usw. Oder das Skript wird doppelt gestartet...

Nein das kann/konnte in diesem Fall ausgeschlossen werden.

Ich glaube auch, dass er den String nicht findet, aber er ist tatsächlich vorhanden, bei einigen funktioniert es, bei anderen nicht. Kann irgendwas in der erwähnten Zeile von System zu System anders interpretiert werden?

Die Datei, in der gesucht wird, wird normalerweise nie geändert, sie beinhaltet nur regional relevante Daten, wie z.B. Pfad zum regionalen Server, genau diesen benötigen wir.

Zitat von HonniCilest

Nein das kann/konnte in diesem Fall ausgeschlossen werden.

Ich glaube auch, dass er den String nicht findet, aber er ist tatsächlich vorhanden, bei einigen funktioniert es, bei anderen nicht. Kann irgendwas in der erwähnten Zeile von System zu System anders interpretiert werden?

Ja. Welches Encoding wird dort verwendet? Welches Encoding wird in der Batch verwendet? Welches Encoding wird während der Ausführung verwendet?

Gruß

Wo kann ich das nachschauen?

Ein guter Editor sollte dir normalerweise das Encoding einer Datei anzeigen.

chcp zeigt das aktuelle Encoding an bzw. setzt es.

Hmm wenn es mir also richtig angezeigt wird (Notepad++), dann ist alles ANSI.

Das ursprüngliche Problem besteht immernoch, allerdings haben wir jetzt für diesen Fall ein Handling eingebaut, welches einen Default-Wert setzt, was aber in diesem Fall unschön ist... Falls jemand noch eine Erklärung hat, immer her damit! Ich wäre sehr dankbar...

Zitat von HonniCilest

Das ursprüngliche Problem besteht immernoch, allerdings haben wir jetzt für diesen Fall ein Handling eingebaut, welches einen Default-Wert setzt, was aber in diesem Fall unschön ist... Falls jemand noch eine Erklärung hat, immer her damit! Ich wäre sehr dankbar...

Problem gelöst, zumindest für einige Anwender, vermeintliche Leerzeichen waren keine Leerzeichen, sie waren einfach nicht druckbare Zeichen. Wie diese dort hineingeraten sind ist unklar, jedoch hatten einige Systeme mit diesen Zeichen Probleme andere wiederum nicht.

Typisches Encoding-Problem.
Aus genau diesem Grund finde ich den Notepad++ nicht so prall. Ich habe mich an den Notepad2 gewöhnt. Gut ... er hat jetzt kein Tabbing und Auch keine Block-Erkennung ... aber was Zeichen zwischen 0x00 und 0x20 angeht zeigt er diese mit ihrem "Namen" gemäß der Tabelle http://de.wikipedia.org/wiki/ASCII#Zusammensetzung an. So sieht man sofort ob es wirklich ein Whitespace-Character oder ein Steuerzeichen ist. Leider schafft er es nicht TAB und SPACE zu differenzieren ... es ist aber einstellbar wie er mit TAB umgeht ... aber da beide offizielle Whitespaces-Charater sind und es in einer URI kein TAB *also \t* geben sollte sollte das eigentlich keine Probleme machen.

Ich muss mich mal informieren, ob ich an meinem Arbeitsplatz Notepad2 installieren darf, danke für den Tipp!

Das ist das schöne : Notepad2 braucht keine Installation ! Du läds einfach die EXE dierekt runter und startest sie. Auch alle Einstellungen werden in einer INI die sich im selben Verzeichnis befindet gespeichert ... kein Stress mit Veränderung der Registry.