View Full Version : Java renameTo() über Verzeichnisse hinweg
QOpenSys wäre noch einen Versuch wert, das ist ein Unix like Dateisystem im IFS.
D*B
Wenn ich mit WRKLNK den Inhalt des Verzeichnis /QOpenSys/QIBM/UserData anzeige, wird mein Verzeichnis "Import" darin interessanter Weise gar nicht aufgelistet. Gebe ich /QIBM/UserData ein, wird es aufgeführt. Habe ich beim Erstellen des Verzeichnisses Import evtl. schon etwas falsch gemacht? *grübel
Titus
Am einfachsten geht das an der Qshell, das ist eine Art kastrierte Unix Shell, die vom OS/400 prompt mit QSH gestartet wird. Von da kann man sich dann mit pwd, cd und ls durchmanövrieren (Die Mausschieber Fraktion kann auch mit Ooops Nerv oder Windoof Explorer rumhampeln).
Geht man zur root (cd /) und macht dort ls, dann sieht man, dass die unterschiedlichen File Systeme der AS/400 dort als toplevel Verzeichnisse zu sehen sind (deswegen Integrated FileSystem).
Dein QIBM/UserDate ist dann ein Ast des sogenannten root FileSystems.
Willst du deine Dateien ins QOpenSys verlegen, musst du die dort ein Verzeichnis anlegen und dann die Dateien halt dort hinverlegen.
D*B
D*B
Wenn ich mit WRKLNK den Inhalt des Verzeichnis /QOpenSys/QIBM/UserData anzeige, wird mein Verzeichnis "Import" darin interessanter Weise gar nicht aufgelistet. Gebe ich /QIBM/UserData ein, wird es aufgeführt. Habe ich beim Erstellen des Verzeichnisses Import evtl. schon etwas falsch gemacht? *grübel
Titus
Q-IFS's sollten auch nach Möglichkeit nicht verwendet werden.
Dafür gibts das Root-Verzeichnis "/Home", in dem man dann z.B. pro User oder Anwendung Unterverzeichnisse anlegen sollte.
Das hat aber nichts mit dem Unterschied REN bzw. MOV zu tun.
Der MOV geht (manchmal) sogar soweit, intern erst einen CPY und dann einen DEL zu verwenden, wenn der MOV über IFS-Grenzen (also unterschiedliche Root's) geht und somit ein tatsächlicher MOV nicht funktioniert.
Ich denke, dass deshalb der REN (bzw. das Java-Äquivalent) eben eingeschränkt ist.
Ich hätte die Dateien auch lieber in einem Unterverzeichnis von /home oder/var. Irgend jemand hat die Verzeichnisstruktur vor längerer Zeit mal in /QIBM/UserData angelegt. Sie jetzt an einen anderen Ort zu verschieben, wäre organisatorisch zu aufwändig.
Ich habe nun erstmal den Workaround mit Copy/Delete programmiert.
Danke trotzdem für eure interessanten Hinweise.
Titus
... interessant wäre noch, ob das eventuell an Berechtigungen stirbt, oder das AS400 JDK den RNM statt des mächtigeren MOV verwendet.
Wenn es bei deinem Workaround bleiben sollte, würde ich den in einer eigenen Extension von java.io.file mit überschriebener renameTo() und einer Factory Methode verbergen und in der Applikation das verwendete Objekt als File deklarieren und von der Factory Methode (oder per Reflection) erstellen lassen.
D*B
Ich hätte die Dateien auch lieber in einem Unterverzeichnis von /home oder/var. Irgend jemand hat die Verzeichnisstruktur vor längerer Zeit mal in /QIBM/UserData angelegt. Sie jetzt an einen anderen Ort zu verschieben, wäre organisatorisch zu aufwändig.
Ich habe nun erstmal den Workaround mit Copy/Delete programmiert.
Danke trotzdem für eure interessanten Hinweise.
Titus
... interessant wäre noch, ob das eventuell an Berechtigungen stirbt, oder das AS400 JDK den RNM statt des mächtigeren MOV verwendet.
D*B
Ja, das würde mich auch interessieren. Und war auch eine Frage in meinem ersten Posting zu diesem Thema: Wie kann ich feststellen, was genau die Ursache für das Scheitern des renameTo() ist?
Titus
... am ehesten mit einem Testprogramm, das den renameTo isoliert und in einem interaktiven Job ohne das ganze WAS Gerümple ausgeführt wird, oder Audit Journal wäre noch ein Ansatz.
D*B
Ja, das würde mich auch interessieren. Und war auch eine Frage in meinem ersten Posting zu diesem Thema: Wie kann ich feststellen, was genau die Ursache für das Scheitern des renameTo() ist?
Titus