Nous avons été confrontés à un problème très étrange qui nous a rendus fous. 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\share\bug
) Et exécutez ce script PowerShell à partir de 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 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 de 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 du répertoire sur alpha
PC dans l'Explorateur Windows en temps réel, car si vous ouvrez ce répertoire dans l'Explorateur, aucun bogue ne se produirait! Assurez-vous donc de 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 démarre toujours à partir de 0.txt).
Nous avons actuellement 2 solutions de contournement pour ce problème:
Quelqu'un a-t-il déjà découvert un problème similaire et peut-il expliquer pourquoi il 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 d'annuaire SMB2, qui est l'un des composants du cache du redirecteur client SMB2 :
Il s'agit d'un cache des énumérations d'annuaires récentes effectuées par le client. Les demandes d'énumération suivantes 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 de répertoire pour déterminer la présence ou l'absence d'un fichier dans le répertoire et utilise ces informations pour empêcher les clients de tenter à plusieurs reprises d'ouvrir des fichiers dont on sait qu'ils n'existent pas sur le serveur. Ce cache est susceptible d'affecter les applications distribuées s'exécutant sur plusieurs ordinateurs accédant à un ensemble de fichiers sur un serveur - où les applications utilisent un mécanisme hors bande pour se signaler mutuellement la modification/l'ajout/la suppression de fichiers sur le serveur.
La valeur par défaut de ce merveilleux petit cache est de 10 secondes, ce qui produit le comportement que vous voyez. Lorsque votre code demande au système ce répertoire/fichier, il obtient le résultat mis en cache, qui date de 10 secondes, il indique donc que le fichier n'existe pas. Réglage HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters\DirectoryCacheLifetime
(DWORD) à une valeur de 0
va désactiver le cache et résoudre le problème de fichier n'existe pas. Étonnamment, ce changement ne nécessite pas un 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 par rapport au forçage de SMB1.
En outre, le cache n'est pas utilisé lorsque le partage en question est ouvert dans l'Explorateur Windows, car son ouverture indique au système de contourner le cache pour maintenir une vue en direct. Cependant, la modification de quelque chose dans le partage via le code 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 pas le confirmer absolument. C'est toujours un problème dans les versions modernes de Windows. Voir les commentaires ci-dessous pour plus de détails.
Un mois s'est écoulé et aucune réponse ...
Nous sommes donc restés avec "Disable SMB 2.0
"solution. Au moins ça marche.
http://www.petri.co.il/how-to-disable-smb-2-on-windows-Vista-or-server-2008.htm
Vous pouvez utiliser le suffixe magique $NOCSC$
, au lieu de désactiver SMB ou la mise en cache via les clés de registre, comme certains l'ont suggéré. Cela vous permettra de laisser tous les paramètres Windows intacts, mais en même temps, les fichiers ne seront pas mis en cache.
Voici un exemple spécifique à une question: \\beta$NOCSC$\share\bug\1.txt
Cochez ce lien si vous souhaitez plus de détails:
http://blog.wisefaq.com/2016/01/26/nocscno-client-side-caching/
Il existe également un bogue dans Windows 7 SP1 pour lequel un correctif est disponible
La façon la plus simple de contourner ce problème (comme suggéré par l'OP) est de créer un fichier temporaire ou un sous-dossier dans le dossier où vous vous attendez à ce que les fichiers apparaissent et de 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 aide également, même s'il ne fait rien.