Please note, I copied this question from SO, because understood that ServerFault is better place for such kind of questions (https://stackoverflow.com/questions/5159220)


We were faced with very strange issue that made us crazy. Sometimes newly created files on our File Share PC were "absent" for some period of time. To reproduce a problem you should have at least two computers, call them alpha and beta. Create file share on beta PC (\\beta\share\bug) and run this PowerShell script from alpha PC:

$sharePC = ($sharePath -split '\\')[2]
$session = New-PSSession -ComputerName $sharePC
$counter = 0
while ($true) {
  $fileName = $sharePath + "\$counter.txt"
  Invoke-Command -Session $session -ScriptBlock {
    "" > $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

After starting this script you should be able to see these messages:

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

And now: Open cmd.exe and run this command:

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

After this you'll during approx 10 seconds you'll see following messages:

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

We've discovered that bug is caused by enumerating shared directory where new files are being created. In Python call os.listdir('//beta/share/bug') to reproduce a bug. In C#: Directory.GetDirectories(@"\\beta\share\bug"). You can even simply navigate to share directory by shell and call ls or dir.

Bug were found on Windows Server 2008 R2. Bug also can be reproduced on Windows 7 (on both OSs SMB 2.0 is installed)

Note, that you cannot watch directory content on alpha PC in Windows Explorer in real time, because if you open this directory in Explorer bug would not occur! So ensure to close all such windows before attempts to reproduce a bug. After each script restart you should manually remove all already created files from share (because script is rather stupid and always starts from 0.txt).

We currently have 2 workarounds for this issue:

  1. If client sees this situation, it creates some temporary file in problematic directory - after this files magically appear.
  2. Disable SMB 2.0: http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

Does anybody have ever discovered similar problem and can explain why it occurs and how "correctly fix" it?


  • One point to clarify...you said that one workaround is to create a temp file then everything appears. Does that mean that in your counting-up script, each file you create means all the previous files appear, since each created file would be like creating a temp file? – Bart Silverstrim Mar 2 '11 at 16:21
  • Is there something related to the process not releasing a file handle before the files appear in directory listings? – Bart Silverstrim Mar 2 '11 at 16:22
  • If you have a person on computer B creating files on a share on computer A, you're saying that someone on computer C can't browse to \\a\share and hit refresh to have the files made by B show up? For how long? Any indication how long that takes for them to be listed? – Bart Silverstrim Mar 2 '11 at 16:23
  • Bart, counting loop creates files in remote session on behalf on beta computer, workaround requires alpha's user to create temp file, because beta can always see files it has created. I don't think it is problem with not releasing file handle. About time to wait to files: as I mentioned in post it is approx 10 seconds. And yes, that someone wouldn't see new files in case of described issue. – Roman Mar 2 '11 at 16:56
  • I am having problems here. Does anyone have any idea what is causing it. I would prefer not to change the smb version as 2.x offers significant speed improvements over 1.0 – Ablue Dec 17 '12 at 6:14

Our current solution that just works: Disable SMB 2.0 (http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm)


If you are not wanting to downgrade the performance of your smb services modify the following registry settings on your smb client.


set DirectoryCacheLifetime, FileNotFoundCacheLifetime and FileInfoCacheLifetime to 0.

Fix is outlined here and here.

  • I would say this is the way to go. SMB2 has some performance improvements, so disabling SMB2 should only be temporary. – bgarlock May 21 '13 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.