2009-06-06 20 views
5

Estoy tratando de ejecutar un vigilante de archivos a través de una ruta del servidor con el servicio de Windows. Estoy usando mi credencial de inicio de sesión de Windows para ejecutar el servicio, y puedo acceder a este "someServerPath" desde mi inicio de sesión. Pero cuando lo hago desde el FileSystemWatcher arroja:.FileSystemWatcher No se puede acceder a la unidad de red

El nombre del directorio \ someServerPath no es válida excepción"

var fileWatcher = new FileSystemWatcher(GetServerPath()) 
    { 
     NotifyFilter=(NotifyFilters.LastWrite|NotifyFilters.FileName), 
     EnableRaisingEvents=true, 
     IncludeSubdirectories=true 
    }; 

public static string GetServerPath() 
{ 
    return string.Format(@"\\{0}", FileServer1);    
} 

Puede alguien por favor me ayude con esto

Respuesta

9

Tengo proyectos que usan el objeto FileSystemWatcher que supervisa las rutas UNC sin ningún problema.

Supongo que al mirar su ejemplo de código puede ser que esté apuntando al monitor en el servidor raíz (// servername /) que puede no ser un sistema de archivos compartido válido? Sé que devuelve cosas como impresoras, tareas programadas, etc. en Windows Explorer.

Intente apuntar al monitor a compartir debajo de la raíz, algo como // servername/c $/sería un buen ejemplo de prueba si tiene derechos administrativos remotos en el servidor.

+0

Gracias. Este parece ser el problema aquí. –

+1

Parece que no funciona en absoluto con // tsclient/shares en el escritorio remoto. No hay errores, pero cuando los archivos cambian, el monitor no recoge nada. Si intenta asignar // tsclient/share a una unidad, se correlaciona bien, pero FileSystemWatcher arroja un error si especifica la letra de unidad asignada. – Triynko

5

Con? Con respecto a la pregunta actualizada, acepto que probablemente necesite especificar un recurso compartido válido, en lugar de solo el nombre del servidor remoto.

[Actualización] fijo pregunta anterior sobre la excepción con esto:

escribir el nombre como @"\\someServerPath"

El \ se escapó como una sola \

Cuando el prefijo de la cadena con un símbolo @, se no procesa las secuencias de escape.

+0

Éste suena bien, pero yo asumiría el camino es en realidad una variable que se lee desde un archivo de configuración o base de datos. Tal vez debería mostrarnos el código real ... – flipdoubt

+0

Por supuesto, estoy haciendo lo mismo. Además, estoy usando @ "\\ ruta" antes de la variable que devuelve esta ruta. –

+0

Actualicé mi código, espero que obtenga una mejor solución ahora. –

0

¿Hay alguna razón en particular por la que no está ejecutando el FileSystemWatcher en la máquina física que tiene el directorio que desea ver?

+0

Es un servicio de Windows que se ejecuta en un servidor de correo y lee archivos de diferentes ubicaciones en la red. –

+0

editar: servidor * principal –

+0

¿No puedes hacer que los otros servidores "envíen" tus archivos a la principal? –

-2

No puede usar el control de directorios en los recursos compartidos de red, esto es una limitación del sistema operativo, no de .NET.

+0

que quiere decir, vigilante de archivos (debido a la limitación del sistema operativo) no puede vigilar un directorio que está físicamente en algunos otra máquina? –

+0

He utilizado con éxito filewatcher en una ruta mapeada de la misma máquina. Quiero decir, el vigilante de archivos vigila "\\ server \ SharedFolder", mientras que los archivos están en "C: \ serviceFolder \ SharedFolder". Este caso funciona bien, la diferencia aquí es que ambos apuntan a la misma máquina, a diferencia del ejemplo anterior. ¿Ese es el problema? –

+0

Está tratando de darle una pista aquí, solo porque pueda engañar la advertencia mediante el uso de unidades mapeadas no significa que sus relojes realmente * funcionarán *. –

2

Aunque esto ya está respondido, pensé que pondría mi granito de arena porque puede ver este mismo error incluso si proporciona rutas válidas.

Recibirá el mismo error cuando el proceso que ejecuta el vigilante no tiene acceso a la compartición remota. Esto sucederá si el observador está en un servicio que se ejecuta bajo la cuenta del Sistema y el recurso compartido es creado por un usuario. El sistema no tiene acceso a ese recurso y no lo reconocerá, deberá hacerse pasar por el usuario para obtener acceso.

1

aunque puede usar un FileWatcher a través de la red, deberá tener en cuenta otros factores, como la desconexión del recurso compartido de red. Si su conexión a la acción finaliza (mantenimiento, retraso, reinicio del equipo, etc.) ya no tendrá un identificador válido en el archivo en su archivo vigilante

2

Me acaban de hacer esta pregunta con respecto al código FileSystemWatcher ejecutándose como servicio y el problema es permisos. Busqué y encontré esta pregunta y respuesta, pero desafortunadamente ninguna de las respuestas aquí resolvió el problema. De todos modos, simplemente lo resolví, así que pensé en arrojar la solución aquí para el siguiente tipo que busca y encuentra esta pregunta.

se asignó la unidad como un usuario conectado pero el servicio se ejecuta como LocalSystem . LocalSystem es una cuenta diferente y no tiene acceso a las unidades mapeadas por un usuario.

La solución puede ser:

  1. autenticarse primero (yo uso un C# Class to establish a network connection with credentials)
  2. Ejecutar su servicio como un usuario que tiene acceso al recurso compartido.

Puede probar la autenticación de sistema local mediante el uso de un símbolo del sistema LocalSystem, ver How to open a command prompt running as Local System?

+0

La mejor solución podría ser usar la cuenta ** NetworkService ** con los permisos correctos en la unidad/carpeta. Un enlace sobre el tema: [Usando NetworkService] (http://stackoverflow.com/questions/11978054/cannot-start-windows-service-in-networkservice-account) – Ethenyl

+1

Creo que esta es la respuesta correcta, yo Tengo el mismo problema, si ejecuto el servicio porque la aplicación de la consola funciona bien, de lo contrario no puedo encontrar la ruta de la red. – Draiden

Cuestiones relacionadas