Problem mit Mac OS X und Dir() (LS)

[semtex]

Hi Leute,
mal wieder ein Problem.

Ich muss auf das Filesystem einer OS X-Maschine zugreifen.
Dabei muss ich überprüfen, ob es ein (temporäres) Verzeichnis schon gibt und wenn nicht wird es angelegt. Dies habe ich beim Windows-PC problemlos folgendermaßen gelöst:

Code

If Dir$(tmpDir , 16)="" Then
   Mkdir tmpDir
End If

Leider funktioniert das Ganze auf'm OS X nicht. Die Designer-Hilfe sagt zum Thema "Macintosh platform differences in LotusScript" lediglich:

Dir: Ignores the attributes Hidden Files, and System. Does not return the directory specifications "." and "..". Returns all files for "*.*", not just those containing ".". Returns only those files ending with a period for "*.", not every file without an extension. If ATTR_VOLUME only is specified, returns the empty string.  If any other attribute is specified, ATTR_VOLUME is ignored.

Irgendwie werde ich daraus nicht schlau. Kann mir jemand helfen???
Wie immer vielen Dank schon mal im Voraus!
Cheers,
semtex

[m3]

Könntest Du "funktioniert das Ganze auf'm OS X nicht" etwas genauer spezifizieren. Welche Fehlermeldung, ertwartetes vis a vis tatsächliches Verhalten, ....

[semtex]

Hi,

also die Fehlermeldung lautet "Path not found".
Soweit ich alle potentiellen Fehlerquellen ausschließen konnte, muss es am Dir()-Aufruf liegen. Erst dachte ich, dass es am MkDir() liegt, das Verzeichnis kann ich aber problemlos erstellen (wenn es noch nicht exisitiert).
Will ich aber Überprüfen, ob es das Verzeichnis schon gibt (wie erwähnt mit dir()), dann kommt die obige Fehlermeldung.
Komisch, komisch, aber ich kann mir momentan nur erklären, dass die Dir()-Funktion auf'm Mac anders funktioniert, oder?

Wie gesagt, ich bin dankbar für jede Anregung!

[m3]

Wie schaut denn der Pfad aus? Beispiel für einen zu überprüfenden Pfad?

[semtex]

Hallo,
das Verzeichnis soll ins Data-Verzeichnis der Notes-Installation.

Der Pfad wird folgendermaßen ermittelt:

Code

notesDir = session.GetEnvironmentString("Directory", True)
tmpDir = notesDir & seperator & "temp"

"seperator" deshalb, da win32 ja mit \ und OS X mit : arbeitet.

D.h. bei Windows sieht der Pfad (also tmpDir) z.B. so aus: C:\Programme\lotus\notes\data\temp
Bei OS X z.B. so: MacHD:Programme:lotus:notes:data:temp
Abhängig davon, wo die Notes-Installation liegt.

Das Kopieren einer Datei mit diesem Pfad funktioniert auch (bei win & mac).
Hast Du eine Idee?

Danke,
semtex

P.S.: Ich brauch jetzt erst mal Feierabend, also nicht wundern wenn heute kein Feedback mehr kommt! Danke!

[semtex]

Hallo noch mal,

ich hab mal weitergeforscht.
Das Problem auf dem Mac ist, dass, falls das Verzeichnis nicht vorhanden ist, die Überprüfung mit Dir() (s.o.) den Fehler verursacht. Gibt es einen andere Funktion, um das Vorhandenseins eines Verzeichnises im Filesystem zu überprüfen?

Hat niemand eine Idee?
Jeder Vorschlag ist willkommen!

Danke,
semtex

[Semeaphoros]

Wenn das konsistent ist, kannst Du das doch mit On Error abfangen?

[semtex]

Hi,

genau diesen Einfall hatte ich auch gerade.
Bin gerade am Testen. Ist zwar nicht unbedingt die eleganteste Art, könnte aber funktionieren. 

Ich meld mich dann noch mal, ob's geklappt hat!

Danke soweit!

[Semeaphoros]

Hmm, was mich mehr nachdenklich macht ist die Tatsache, dass hier offenbar das Errorhandling insgesamt fehlt ...... 

[semtex]

Naja, zugegebenermaßen bin ich nicht der größte Verfechter des Errorhandlings.
Mag was mit Faulheit zu tun haben. 

Aber an den relevanten Stellen habe ich schon genau darauf geachtet, dass Fehler abgefangen werden und schlüßige Meldungen ausgeben werden.
Mit der Dir()-Funktion hatte ich bisher nur noch nie Probleme (da bisher nur Windows-Kisten bedient wurden), so dass ich hier die Fehlerbehandlung unterschlagen habe. Muss ich jetzt wohl nachholen.....

[semtex]

Also, hier meine Lösung:

Wie oben schon angesprochen habe ich das Ganze über das Errorhandling gelöst.
Tritt ein Fehler bei der Dir()-Abfrage auf, existiert das Verzeichnis nicht und muss (mit MkDir)erzeugt werden.
Tritt der Fehler nicht auf, d.h. dir() gibt entweder einen leeren String oder den Namen der ersten Datei zurück, muss das Verzeichnis nicht angelegt werden und das Skript wird ganz normal weiterbearbeitet.

Ist zwar "von hinten durch die Brust ins Auge", aber wenns funzt....

Danke nochmals,
semtex

[koehlerbv]

Sauberes Funktionieren der Dir-Function (und ChDir / MkDir etc.) bekommst Du auch unter Windows nur mit einem noch saubereren ErrorHandling hin. Das werden auch andere Forums-Mitglieder bestätigen können. Ich sehe das also nicht (oder wenn nur in einem speziellen Fall) als MacOS.Problem an.

Bernhard

[Semeaphoros]

Genau so ist es.

[koehlerbv]

Das war schon mal eine massgebliche Bestätigung 

@semtex: Nimm ErrorHandling sehr, sehr ernst. Ich bin lange genug in dem Job und bin mir ABSOLUT sicher, dass diese meine Meinung nicht nur eine, sondern DIE allgemeine Verbindlichkeit in sich trägt.

Bernhard

[Marinero Atlántico]

Wenn ich Semtex richtig verstanden habe, verwendet er das Errorhandling als Teil der Programmlogik.
Normalerweise soll ja ein Error eine Ausnahmebedingung sein.
Hier ist sie aber Bestandteil der Programmlogik.
Das gilt nicht als die feine englische, funzt aber tatsächlich.
Es gibt aber, wenn ich mich recht erinnere, noch eine andere Art, um nachzufragen, ob ein Directory existiert. Hab ich aber leider momentan vergessen.

[Semeaphoros]

Das ist richtig, allerdings prallen da verschiedene Philosophien aufeinander, die eine, bei der Fehler schon gar nicht vorkommen sollten, die andere, wo Fehler geradezu - wie Du sagst - logisch genutzt werden. Basic hat - aus Tradition gewachsen - Bestandteile beider Philosphien. Dir ist so ein Beispiel, wo das Errorhandling in den Logikablauf einbezogen werden muss und kein "Exception handling" mehr ist. Alternativen, die nicht Windows-Spezifisch sind, kenne ich nicht. Natürlich gibt es unter Windows andere Möglichkeiten, zum Bleistift das Oeffnen des Filesystem-Objektes über COM.

[koehlerbv]

Natürlich gibt es unter Windows andere Möglichkeiten, zum Bleistift das Oeffnen des Filesystem-Objektes über COM.

... oder WinAPI, aber das hilft uns ja bekanntermassen und wie von Dir auch genannt nicht die erwartete Lösung. Richtig lustig wird es dann mit "Hannover", wenn zahlreiche*) weitere Betriebssysteme hinzukommen (Linux) - OS-spezifische Sachen werden dann eine weitere Herausforderungsstufe darstellen (der wir uns gerne annehmen werden).

Bernhard

*) Das war ernst gemeint.

[Marinero Atlántico]

Zumindest Performance-Verluste muß man im Kauf nehmen. Das Fehler werfen, Fehler abfangen kostet auf jeden Fall extra-Ressourcen. Ob man die merkt, ist eine andere Frage.
Ausserdem würde ich es auf jeden Fall mit einem Kommentar kennzeichnen. Ansonsten können nachfolgende Generationen verwirrt werden. Man rechnet nicht unbedingt damit. 

[Marinero Atlántico]

... oder WinAPI, aber das hilft uns ja bekanntermassen und wie von Dir auch genannt nicht die erwartete Lösung. Richtig lustig wird es dann mit "Hannover", wenn zahlreiche*) weitere Betriebssysteme hinzukommen (Linux) - OS-spezifische Sachen werden dann eine weitere Herausforderungsstufe darstellen (der wir uns gerne annehmen werden).

@Bernhard: Hannover ist ein Java-Client und zumindest die Überprüfung des Vorhandenseins von Dateien ist in Java seit 1995 oder 1996 gelöst.
Da IBM die Offenheit von Eclipse nutzen will, wird es überall Schnittstellen geben, wo man eigene Java-Klassen gemäss der  Eclipse-Architektur einpluggen kann. Also braucht man keinen plattformspezifischen Code.

[koehlerbv]

Genau da sehe ich das Problem, Axel:
Welche Java-Version meinst Du ? Welche OS-Version meinst Du (Linuxe gibt es ja wie Sand am Meer), welche classes meinst Du - auch da fehlen ja Standards (wobei wir wieder bei der installierten Java-Version wären).
"Hannover" muss noch ein weiteres Problem lösen, was es sich ja auch auf die Fahnen geschrieben hat: Es muss auch den LS-Code beherrschen und "irgendwie" umsetzen.

"Hannover" geht aus meiner Sicht der Dinge in die notwendige Richtung. Probleme gibt es aber noch genug.

To be continued ...

Bernhard