Partage de fichiers Windows: pourquoi parfois les fichiers nouvellement créés ne sont pas visibles pendant un certain temps?

Nous avons été confrontés à une question très étrange qui nous a rendu fou. Parfois, les fichiers nouvellement créés sur notre PC de partage de fichiers étaient “absents” pendant un certain temps. Pour reproduire un problème, vous devez avoir au moins deux ordinateurs, appelez-les alpha et beta . Créez un partage de fichiers sur beta PC beta ( \\beta\share\bug ) et exécutez ce script PowerShell à partir d’ alpha PC:

 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 } 

Après avoir démarré ce script, vous devriez pouvoir voir ces messages:

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

Et maintenant : Ouvrez cmd.exe et exécutez cette commande:

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

Après cela pendant environ 10 secondes, vous verrez les messages suivants:

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

Nous avons découvert que le bogue est causé par l’énumération du répertoire partagé dans lequel les nouveaux fichiers sont créés. Dans Python appelez os.listdir('//beta/share/bug') pour reproduire un bogue. Dans C# : Directory.GetDirectories(@"\\beta\share\bug") . Vous pouvez même simplement naviguer pour partager le répertoire par shell et appeler ls ou dir .

Un bug a été trouvé sur Windows Server 2008 R2

Notez que vous ne pouvez pas regarder le contenu des répertoires sur alpha PC dans l’Explorateur Windows en temps réel, car si vous ouvrez ce répertoire dans Explorer, le bogue ne se produirait pas! Veillez donc à fermer toutes ces fenêtres avant de tenter de reproduire un bogue. Après chaque redémarrage du script, vous devez supprimer manuellement tous les fichiers déjà créés du partage (car le script est plutôt stupide et commence toujours à partir de 0.txt).

Nous avons actuellement 2 solutions de contournement pour ce problème:

  1. Si le client voit cette situation, il crée un fichier temporaire dans le répertoire problématique – une fois que ces fichiers apparaissent comme par magie.
  2. Désactiver SMB 2.0: http://www.pesorting.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

Quelqu’un a-t-il déjà découvert un problème similaire et peut-il expliquer pourquoi cela se produit et comment le corriger correctement?

Merci

    Je rencontrais un problème similaire et, finalement, j’ai trouvé la cause de ce problème. Le problème spécifique est le cache de répertoire SMB2, qui est l’un des composants de cache du redirecteur client SMB2 :

    Ceci est un cache des énumérations de répertoires récentes effectuées par le client. Les requêtes d’énumération ultérieures effectuées par les applications clientes ainsi que les requêtes de métadonnées pour les fichiers du répertoire peuvent être satisfaites à partir du cache. Le client utilise également le cache d’annuaire pour déterminer la présence ou l’absence d’un fichier dans l’annuaire et utilise ces informations pour empêcher les clients d’essayer à plusieurs resockets d’ouvrir des fichiers dont l’existence est inconnue sur le serveur. Ce cache est susceptible d’affecter les applications dissortingbuées exécutées sur plusieurs ordinateurs accédant à un ensemble de fichiers sur un serveur – les applications utilisant un mécanisme hors bande pour se signaler les modifications / ajouts / suppressions de fichiers sur le serveur.

    La valeur par défaut de ce merveilleux cache est de 10 secondes, ce qui produit le comportement que vous voyez. Lorsque votre code demande au système à propos de ce répertoire / fichier, il obtient le résultat mis en cache, qui a 10 secondes, il dit donc que le fichier n’existe pas. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters\DirectoryCacheLifetime valeur 0 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters\DirectoryCacheLifetime (DWORD), le cache sera désactivé et le fichier ne sera pas résolu. Étonnamment, ce changement ne nécessite pas de redémarrage de la machine cliente! Cela vous permettra également de garder SMB2 activé, ce qui devrait être préférable pour un certain nombre de raisons vs forcer SMB1.

    En outre, le cache n’est pas utilisé lorsque le partage en question est ouvert dans l’explorateur Windows, car le fait de l’avoir ouvert indique au système de contourner le cache pour conserver une vue en direct. Modifier quelque chose dans le partage via le code, cependant, ne le fait pas.

    Je pense que tout ce problème est résolu dans Windows 2008 R2 / 7 et supérieur, mais je ne peux absolument pas le confirmer. Ceci est toujours un problème dans les versions modernes de Windows. Voir les commentaires ci-dessous pour plus de détails.

    Un mois a passé et pas de réponse …

    Nous sums donc restés avec la solution ” Disable SMB 2.0 “. Au moins ça marche.

    http://www.pesorting.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

    Il existe également un bogue dans Windows 7 SP1 pour lequel un correctif est disponible

    Le fichier ajouté par un utilisateur à un dossier distant ne s’affiche pas dans l’Explorateur Windows sur un ordinateur exécutant Windows 7 ou Windows Server 2008 R2

    Vous pouvez utiliser le suffixe magique $NOCSC$ au lieu de désactiver SMB ou la mise en cache via des clés de registre, comme d’autres l’ont suggéré. Cela vous permettra de laisser tous les parameters Windows intacts, mais en même temps, les fichiers ne seront pas mis en cache.

    Voici une question exemple spécifique: \\beta$NOCSC$\share\bug\1.txt

    Cochez ce lien si vous voulez plus de détails:

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

    Le moyen le plus simple de contourner ce problème (comme suggéré par l’OP) consiste à créer un fichier ou un sous-dossier temporaire dans le dossier dans lequel les fichiers doivent apparaître et à le supprimer immédiatement. Cela déclenche le changement pour devenir visible.

    Nous avons remarqué que le fait d’avoir un FileSystemWatcher dans le dossier est également utile, même s’il ne fait rien.