una hogar grupo crear contraseña compartir como carpetas carpeta archivos windows share smb

hogar - compartir carpeta windows 10 wifi



Compartir archivos de Windows: ¿por qué a veces los archivos recién creados no son visibles por un período de tiempo? (5)

Nos enfrentamos a un tema muy extraño que nos volvió locos. A veces, los archivos recién creados en nuestra PC File Share estaban "ausentes" por algún tiempo. Para reproducir un problema debes tener al menos dos computadoras, llámalas alpha y beta . Cree un recurso compartido de archivos en beta PC beta ( //beta/share/bug ) y ejecute este script de PowerShell desde alpha PC alpha :

param( $sharePath="//beta/share/bug" ) $sharePC = ($sharePath -split ''//')[2] $session = New-PSSession -ComputerName $sharePC $counter = 0 while ($true) { $fileName = $sharePath + "/$counter.txt" Invoke-Command -Session $session -ScriptBlock { param( $fileName ) "" > $fileName } -ArgumentList $fileName if (Test-Path $fileName) { Write-Host "File $fileName exists" -fore Green } else { Write-Host "!!! File $fileName does NOT exist!" -fore Red } $counter = $counter + 1 Start-Sleep 2 }

Después de iniciar este script, debería poder ver estos mensajes:

File //beta/share/bug/1.txt exists File //beta/share/bug/2.txt exists ...

Y ahora : abra cmd.exe y ejecute este comando:

if exist //beta/share/bug/foo.txt echo 1

Después de esto, durante aproximadamente 10 segundos, verá los siguientes mensajes:

!!! File //beta/share/bug/3.txt does NOT exist! !!! File //beta/share/bug/4.txt does NOT exist!

Hemos descubierto que el error se debe a la enumeración del directorio compartido donde se crean los nuevos archivos. En Python llame a os.listdir(''//beta/share/bug'') para reproducir un error. En C# : Directory.GetDirectories(@"//beta/share/bug") . Incluso puede simplemente navegar para compartir el directorio por shell y llamar a ls o dir .

Se encontraron errores en Windows Server 2008 R2

Tenga en cuenta que no puede ver el contenido del directorio en alpha PC en el Explorador de Windows en tiempo real, porque si abre este directorio, ¡no ocurrirá el error! Así que asegúrate de cerrar todas estas ventanas antes de intentar reproducir un error. Después de cada reinicio de la secuencia de comandos, debe eliminar manualmente todos los archivos ya creados del recurso compartido (porque la secuencia de comandos es bastante estúpida y siempre comienza desde 0.txt).

Actualmente tenemos 2 soluciones para este problema:

  1. Si el cliente ve esta situación, crea algún archivo temporal en el directorio problemático, después de que estos archivos aparezcan mágicamente.
  2. Deshabilitar SMB 2.0: http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

¿Alguna vez alguien ha descubierto un problema similar y puede explicar por qué ocurre y cómo "solucionarlo correctamente"?

Gracias


Estaba experimentando un problema similar y, finalmente, encontré la causa de este problema. El problema específico es el caché de directorio SMB2, que es uno de los componentes del caché del Redirector de cliente SMB2 :

Este es un caché de las enumeraciones de directorio recientes realizadas por el cliente. Las solicitudes de enumeración posteriores realizadas por las aplicaciones cliente, así como las consultas de metadatos para los archivos en el directorio pueden satisfacerse desde el caché. El cliente también utiliza el caché del directorio para determinar la presencia o ausencia de un archivo en el directorio y utiliza esa información para evitar que los clientes intenten abrir repetidamente archivos que se sabe que no existen en el servidor. Es probable que esta memoria caché afecte a las aplicaciones distribuidas que se ejecutan en varios equipos que acceden a un conjunto de archivos en un servidor, donde las aplicaciones utilizan un mecanismo fuera de banda para señalarse mutuamente sobre la modificación / adición / eliminación de archivos en el servidor.

El valor predeterminado para este pequeño y maravilloso caché es de 10 segundos, que está produciendo el comportamiento que estás viendo. Cuando su código le pregunta al sistema acerca de ese directorio / archivo, está obteniendo el resultado en caché, que tiene 10 segundos de antigüedad, por lo que dice que el archivo no existe. Establecer HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Lanmanworkstation/Parameters/DirectoryCacheLifetime (DWORD) en un valor de 0 deshabilitará el caché y resolverá que el archivo no existe problema. ¡Sorprendentemente, este cambio no requiere un reinicio de la máquina cliente! Esto también le permitirá mantener SMB2 habilitado, lo que debería ser mejor por varias razones en lugar de forzar SMB1.

Además, el caché no se usa cuando el recurso compartido en cuestión se abre en el explorador de Windows, ya que tenerlo abierto le indica al sistema que omita el caché para mantener una vista en vivo. Modificar algo en el código compartido a través de código, sin embargo, no lo hace.

Creo que todo este problema está solucionado en Windows 2008 R2 / 7 y superior, pero no puedo confirmarlo por completo. Esto sigue siendo un problema en las versiones modernas de Windows. Vea los comentarios a continuación para más detalles.


La forma más fácil de solucionar esto (como lo sugiere el OP) es crear un archivo o subcarpeta temporal en la carpeta donde espera que aparezcan los archivos y eliminarlos de inmediato. Esto provoca que el cambio se haga visible.

Notamos que tener un FileSystemWatcher en la carpeta también ayuda, incluso cuando no hace nada.



Puede usar el sufijo mágico $NOCSC$ , en lugar de deshabilitar SMB o el almacenamiento en caché a través de las claves de registro, como algunos otros sugirieron. Esto le permitirá dejar intactas todas las configuraciones de Windows, pero al mismo tiempo los archivos no se almacenarán en caché.

Aquí hay un ejemplo de pregunta específica: //beta$NOCSC$/share/bug/1.txt

Revisa este enlace si quieres más detalles:

http://blog.wisefaq.com/2016/01/26/nocscno-client-side-caching/