[Java] java.io.IOException: problema di permessi di scrittura?!

[Matrixbob]

Potrebbe essere un problema di permessi di scrittura su filesystem?

Lo stack trace trae in inganno "UnixFileSystem.createFileExclusively", ma penso semplicemente sia un metodo di scrittura delle API della VM per scrivere il filesystem.


Error No such file or directory (errno:2)
java.io.IOException: No such file or directory (errno:2)
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:871)
at mio.pack.ImportManager.load(ImportManager.java:158)
at mio.pack.ImportManager.main(ImportManager.java:71)

[PGI-Bis]

Di solito quando è un problema di permessi del filesystem l'eccezione contiene il messaggio "permission" qualcosa. Lì sembra invece che si stia cercando di creare un file in una cartella che non esiste. Hai modo di verificare il percorso completo del file che il programma vuole creare?

[Matrixbob]

Di solito quando è un problema di permessi del filesystem l'eccezione contiene il messaggio "permission" qualcosa. Lì sembra invece che si stia cercando di creare un file in una cartella che non esiste. Hai modo di verificare il percorso completo del file che il programma vuole creare?

Sono in un ambiente di lavoro quindi non posso modificare a bomba gli eseguibili con una nuova versione. Nella nuova faccio stampare dove scrivo e scrive altrove non più li dentro.
Il mistero è che lanciato manualmente il jar parte e scrive quella cartella, mentre lanciato da shell automatica no.

io ho ipotizzato quindi problemi di permessi oppure problema di mutua esclusione al filesystem?
Voi che dite?

[PGI-Bis]

Se lanciato da jar va e da shell no e cose così allora può essere un problema di "relatività".

Se il programma usa percorsi relativi, tipo:

File x = new File("pippo")

e' come se dicesse:

File x = new File(System.getProperty("user.dir"), "pippo"))

e "user.dir" è variabile. Se lanci da console è la directory corrente della linea di comando, se esegui il jar dovrebbe essere (ma non ci metterei la mano sul fuoco)
la cartella in cui si trova il jar.

[Matrixbob]

Se lanciato da jar va e da shell no e cose così allora può essere un problema di "relatività".

Se il programma usa percorsi relativi, tipo:

File x = new File("pippo")

e' come se dicesse:

File x = new File(System.getProperty("user.dir"), "pippo"))

e "user.dir" è variabile. Se lanci da console è la directory corrente della linea di comando, se esegui il jar dovrebbe essere (ma non ci metterei la mano sul fuoco)
la cartella in cui si trova il jar.
Grazie che mi segui.
L'eseguibile utilizza una variabile d'ambiente $var caricata nel .setenv_utente ... quindi non dovrebbe soffirere di questo problema di relatività.

[PGI-Bis]

Quindi sia da shell che da jar cerca di leggere/scrivere lo stesso percorso? Non vorrei incapponirmi ma secondo me il problema è quello.

[Matrixbob]

Quindi sia da shell che da jar cerca di leggere/scrivere lo stesso percorso? Non vorrei incapponirmi ma secondo me il problema è quello.

CMQ non è una cosa di accesso esclusivo al FS o al file giusto?
Male che vada sta scrivendo chissa chi chissà dove giusto?

"java.io.UnixFileSystem.createFileExclusively(Native Method)" è il metodo delle JVM Unixlike per scrivere un file?

[PGI-Bis]

Chissachi non troppo. Il chi è:

mio.pack.ImportManager.load(ImportManager.java:158)

E' lui perchè più in giù è tutto API e nell'ambito dei file errori nella API sono quantomeno rari (dopo vent'anni che ci sono).

Quella chiamata a UnixFileSystem non ci interessa: è un dettaglio di implementazione del quale non sappiamo nulla, magari non serve neanche a creare un file.

Quello che interesserebbe a me come primissima cosa di fronte ad un problema del genere è sapere il percorso del file a fronte del quale si genera quell'eccezione.

[Matrixbob]

Chissachi non troppo. Il chi è:

mio.pack.ImportManager.load(ImportManager.java:158)

E' lui perchè più in giù è tutto API e nell'ambito dei file errori nella API sono quantomeno rari (dopo vent'anni che ci sono).

Quella chiamata a UnixFileSystem non ci interessa: è un dettaglio di implementazione del quale non sappiamo nulla, magari non serve neanche a creare un file.

Quello che interesserebbe a me come primissima cosa di fronte ad un problema del genere è sapere il percorso del file a fronte del quale si genera quell'eccezione.

Gli arrivava un input sbagliato ed andava a scrivere chissà dove in percorsi che non esistevano assolutamente. :)