> Yo iría por caminos más convencionales. y lo divertido??
> Primero haría una revisión de los NotifyFilters Puede ser, la verdad no le habia prestado atencion a eso... > El problema es el “después” de la acción de borrado Justamente ahi esta el mayor problema... no se me ocurre solucion en ese caso. Saludos! 2009/3/13 Carlos Salvatore <[email protected]>: > Diego, > > Yo iría por caminos más convencionales. > > Primero haría una revisión de los NotifyFilters > (http://msdn.microsoft.com/en-us/library/system.io.notifyfilters.aspx) y > confirmaría cómo responden los filtros de FileName y DirectoryName. Tal vez, > a través del FileName puedas tener evidencia de si el cambio es en un > archivo o en un directorio. > > En segundo lugar, tenés la opción de tomar el nombre > completo del objeto que cambió y probar si el método Directory.Exists te > puede confirmar si se trata de un archivo o de un directorio. El problema es > el “después” de la acción de borrado. En ese caso el objeto en cuestión no > va a existir en el disco y no vas a poder acceder a sus atributos. > > > > Tal vez, podrías crearte un mapa previo de las carpetas que > querés monitorear y ante un cambio notificado por el FileWatcher comparar > con la última versión, procesar los cambios según necesites, y luego > actualizar tu mapa. > > > > C.S. > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Gustavo > Ringel > Sent: Friday, March 13, 2009 06:40 > To: [email protected] > Subject: [puntonet] Clase IO.FileSystemWatcher > > > > Diego, me das miedooooo :) > > Gustavo. > > 2009/3/13 Diego Jancic <[email protected]> > > Hola, > > > > De curioso, investigue un poco porque tenia mis dudas sobre como se guardan > los directorios físicamente en el disco > > Usando reflector sobre la clase FileSystemWatcher me di cuenta de que no hay > nada para hacerlo (a menos que exista algun truco lógico que no conozca). > > Buscando un poco mas internet, encontré esto: > > > > > > > > Q58 How do I determine if the FILE_OBJECT represents a file or a directory > from my filter driver? Can I rely upon the FILE_DIRECTORY_FILE bit? > > The determination of whether or not a given FILE_OBJECT represents a > directory is the sole domain of the file system driver. Thus, for a file > system filter driver to determine if a file is a directory, it must ask the > file system. This can be done by querying the attributes of the file (e.g., > after it has been successfully opened by the underlying file system) or by > examining the attributes within the directory, which can be done before the > underlying file has been opened. > > Options specified during create are not adequate for determining if a file > is, in fact, a directory. For example, an application may optionally specify > that the file being opened must be a directory by setting the > FILE_DIRECTORY_FILE option as part of create (this is a bit in the I/O Stack > location, Parameters.Create.Options, the low 24 bits of which are used for > file options). If the file creation is successful, the file system filter > driver can conclude that the FILE_OBJECT does represent a directory. If the > file creation is successful and the caller did not specify > FILE_DIRECTORY_FILE, however, the caller cannot presume that the file is a > directory. The FILE_NON_DIRECTORY_FILE bit can similarly be used to > determine that the given FILE_OBJECT does not represent a file. > > There is one complication for those writing a file system filter driver - > they must keep in mind that some file options now combine these two bits. > For example FILE_COPY_STRUCTURED_STORAGE (which is not used but is still > present in ntifs.h for Windows XP) is defined as FILE_DIRECTORY_FILE and > FILE_NON_DIRECTORY_FILE. > > Thus, the safest way to determine if a FILE_OBJECT represents a directory > remains to ask the underlying file system. > > > > Fuente: http://www.osronline.com/article.cfm?id=17#Q58 > > > > Si lees la ultima línea, todo hace pensar que es imposible saber lo que > queres una vez que el archivo no existe. Por lo que si quisieses hacerlo > deberías hacer esta verificación *antes* de que el archivo/carpeta sea > modificado o borrado, y despues si es que se esta creando. No se si las APIs > de Windows soportan estos events pre y post cambio al file system. > > > > Saludos, > > Diego > > > > Pd: Dato interesante que descubri cuando usaba reflector: El Filter que se > usa para poner cosas como *.txt, considera exactamente el * y el *.*, aun > cuando no deberían ser lo mismo (el segundo debería filtrar los nombres que > no contiene un punto). > > El código es una cosa asi de sucia y asi de hardcodeado: > > > > if (filter == “*” || filter == “*.*”) > > return true; > > // Empieza la logica real para parsear el * y el ? como debería ser… > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Pablo > Satelier > Sent: Thursday, March 12, 2009 14:02 > To: [email protected] > Subject: [puntonet] Clase IO.FileSystemWatcher > > > > Hola gente,... > > estoy necesitando que la clase IO.FileSystemWatcher me notifique > unicamente los cambios en las carpetas, no en las carpetas que fueron > modificados los archivos que contiene. En cuanto a cambios me refiero a > renombrado, eliminacion o creacion de una carpeta. No se si esto se puede > hacer con el FileSystemWatcher o si existe alguna otra clase que pueda hacer > lo que necesito. > > Alguna idea?? > > Muchas gracias de antemano !! > > Saludos, Pablo.- > >
