saber - metodo exists java
FileNotFoundException lanzado cuando el archivo existe (4)
Estoy enfrentando este extraño problema.
Intento leer un archivo que está ubicado en otra máquina como un recurso compartido:
//remote-machine/dir/MyFileHere.txt
Cuando ejecuto una aplicación independiente (un archivo java de 16 líneas) todo está bien. Pero cuando intento leer el mismo archivo usando la misma clase y el mismo método desde un "motor" de servidor (este es un motor de aplicaciones, más o menos como un servidor de aplicaciones Java EE donde se pueden ejecutar programas Java) la "excepción FileNotFoundException" es aventado.
Pensé que sería algún tipo de permiso, por lo que mapeo el recurso como un disco: K: /
Vuelve a ejecutar mi archivo java, lee, bien.
Vuelve a ejecutar mi archivo java dentro del "motor" -> FileNotFoundException.
Cuando copio el archivo en la máquina local (C: / MyFileHere.txt) no se lanza ninguna excepción.
Pregunta
¿Qué puede estar causando este FileNotFoundExcecption?
Estoy usando Java 1.5
Por lo que sé, el motor prácticamente usa Java de forma transparente.
¿Alguien se ha enfrentado a algo similar?
Pregunta adicional? ¿Cuál sería un buen enfoque para solucionar esto? Estoy empezando a pensar en una instalación de Tomcat que sirva esos archivos y los lea a través de http, pero creo que eso es demasiado, por eso es que el protocolo SMB está en primer lugar, ¿no? Y probablemente no pueda abrir tomas de todos modos.
¿El administrador de seguridad puede ser la causa (nunca he usado eso antes, pero sé que existe)
¿No se lanzaría una SecurityException en su lugar si ese fuera el caso?
Muchas gracias.
EDITAR
Resuelto Gracias Steve W.
Resulta que este motor se lanzó con "LaunchAnywhere" de ZeroG. Entonces, se crea un .exe que a su vez ejecutará una JVM con la aplicación especificada.
Esta aplicación en sí misma es Launcher. Cuando arranca el motor, de alguna manera (no puedo entender por qué o cómo), el usuario que posee el proceso de JVM es SYSTEM. Como Steve señaló, este usuario no tiene acceso a la red, y por lo tanto no puede leer desde un recurso compartido o una unidad mapeada.
La solución alternativa (mientras informo esto al fabricante) es crear un archivo .cmd para activar manualmente el motor. Como se lanzaría manualmente, el usuario tiene acceso a la red.
He usado "Process Explorer" de SysInternals para conocer exactamente la línea de comandos utilizada para ejecutar la aplicación de motor.
¡QUE DESASTRE!
Gracias a quienes publicaron respuestas.
¿El recurso compartido está protegido por un nombre de usuario y contraseña? Y si es así, ¿está funcionando su motor de aplicaciones como ese usuario? Si su motor de aplicaciones se ejecuta como un servicio de Windows, el servicio de Windows no se puede ejecutar como la "cuenta del sistema local". Esta cuenta no puede acceder a la red. Debe configurar su servicio para que se ejecute como un usuario que tiene los derechos para acceder a la unidad compartida.
¿Has revisado los registros de eventos en el servidor para ver si se rechazan? podría ser que el programa se esté ejecutando bajo una cuenta de usuario diferente de lo que piensas.
No estoy familiarizado con Java, pero sé que con algunos programas que he escrito he tenido que permitir que Network Services acceda a los recursos.
De hecho, veo que ahora ha marcado una respuesta como la correcta. Ah, y fue lo mismo que mi respuesta :) Genial!
Tuve un problema similar una vez. Creo que tiene que ver con la forma en que java resuelve los URI de los archivos remotos. Pruebe lo siguiente y vea si funciona:
Archivo: ////remote-machine/dir/MyFileHere.txt
Usé el siguiente ejemplo para verificar la existencia de un archivo en carpetas compartidas en mi cuadro y funcionó:
public static void main(String[] args) throws URISyntaxException{
URI uri = new URI(args[0]); //args[0] = File:////remote-machine/dir/MyFileHere.txt
File f = new File(uri);
System.out.print(String.format("File %1$s Exists? %2$s", args[0],f.exists()));
}
Verifique que el archivo se llama REALMENTE "MyFileHere.txt" y no "MyFileHere.txt.txt" Si está ocultando la extensión del archivo, este es un error fácil de perder