Partage de fichiers Windows: pourquoi parfois les fichiers nouvellement créés ne sont pas visibles pour une certaine période de temps?
Nous avons été confrontés à de très étrange question qui nous ont fait le fou. Parfois, les fichiers nouvellement créés sur notre Partage de Fichiers de PC ont été "absent" pendant une certaine période de temps. Pour reproduire le problème, vous devriez avoir au moins deux ordinateurs, appeler alpha et beta. Créer 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 le début de ce script, vous devriez être capable de voir ces messages:
File \\beta\share\bug.txt exists
File \\beta\share\bug.txt exists
...
Et maintenant:
Ouvrir cmd.exe et exécutez cette commande:
if exist \\beta\share\bug\foo.txt echo 1
Après ce pendant environ 10 secondes, vous verrez des messages suivants:
!!! File \\beta\share\bug.txt does NOT exist!
!!! File \\beta\share\bug.txt does NOT exist!
Nous avons découvert que ce bug est causée par l'énumération répertoire partagé lorsque de nouveaux fichiers sont créés. Dans Python appel os.listdir('//beta/share/bug') de reproduire un bug. Dans C#: Directory.GetDirectories(@"\\beta\share\bug"). Vous pouvez même naviguer simplement dans le répertoire de partage par shell et appel ls ou dir.
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 bug n'aurait pas lieu! Afin de s'assurer de fermer tous ces fenêtres avant de tentatives pour reproduire un bug. Après chaque script de redémarrage, vous devez supprimer manuellement tous les fichiers créés à partir de l'action (parce que le script est plutôt stupide et démarre toujours à partir de 0.txt).
Actuellement, nous avons 2 solutions à ce problème:
- Si le client voit cette situation, il crée des fichiers temporaires dans la problématique d'annuaire - après cela, les fichiers apparaissent comme par magie.
- Désactiver SMB 2.0: http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm
Quelqu'ont jamais découvert problème similaire et peut expliquer pourquoi il se produit et comment correctement "réparer"?
Grâce
- Avez-vous regardé une trace réseau pour voir ce qu'il se passe?
- Non, malheureusement, je n'ai pas regardé trace réseau
- Je ne pense pas qu'une trace réseau va aider. Cela semble être un problème de mise en cache côté serveur. Nous avons exactement le même problème à partir de Windows 2003 pour 2012R2. Il semble SMB affiche les fichiers pour le serveur qui les a créés, mais montre ensuite les fichiers n'existent pas encore sur d'autres serveurs que de requête pour eux. Il est assez mauvais.
Vous devez vous connecter pour publier un commentaire.
J'ai été confronté à un problème similaire et, finalement, j'ai trouvé la cause de ce problème. Le problème est le SMB2 Répertoire de Cache, qui est l'un des SMB2 Redirecteur Client cache de composants:
La valeur par défaut pour ce merveilleux petit cache est de 10 secondes, ce qui est en train de produire le comportement que vous vous voyez. Lorsque votre code demande le système sur le répertoire/fichier, il est d'obtenir le résultat mis en cache, qui est de 10 secondes, il dit que le fichier n'existe pas. Réglage
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters\DirectoryCacheLifetime(DWORD) à une valeur de0de désactiver le cache et de résoudre le fichier n'existe pas de problème. Étonnamment, ce changement ne pas nécessitent un redémarrage de l'ordinateur client! Cela vous permettra aussi de garder SMB2 activé, ce qui devrait être mieux pour un certain nombre de raisons vs forcer SMB1.En outre, le cache n'est pas utilisé lorsque l'action en question est ouvert dans l'explorateur Windows, comme ayant ouvert indique que le système ignore le cache de garder une vue en direct va. Modifier quelque chose dans le partage via le code, cependant, ne fonctionne pas.
je pense que l'ensemble de ce problème est résolu dans Windows 2008 R2/7 et supérieur, mais je ne peut absolument pas le confirmer.C'est toujours un problème dans les versions modernes de Windows. Voir les commentaires ci-dessous pour plus de détails.Un mois et pas de réponse...
Donc, nous sommes restés avec "
Disable SMB 2.0" solution. Au moins il fonctionne.http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm
Il y a aussi un bug dans Windows 7 SP1 pour lesquels il existe un correctif disponible
Fichier que l'utilisateur ajoute à une distance de dossier ne s'affiche pas dans l'Explorateur Windows sur un ordinateur qui exécute Windows 7 ou Windows Server 2008 R2
Vous pouvez utiliser magique suffixe
$NOCSC$, au lieu de désactiver le protocole SMB ou la mise en cache via des clés de registre, comme certains d'autres ont suggéré. Cela vous permettra de laisser tous les paramètres de Windows intacte, mais en même temps, les fichiers ne sont pas mis en cache.Voici une question spécifique exemple:
\\beta$NOCSC$\share\bug\1.txtVérifier ce lien si vous souhaitez plus de détails:
http://blog.wisefaq.com/2016/01/26/nocscno-client-side-caching/
La façon la plus simple pour contourner ce (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 supprimer tout de suite. Cela déclenche le changement pour devenir visible.
Nous avons remarqué que le fait d'avoir un
FileSystemWatcherdans le dossier permet également, de même quand il ne fait rien.