Anmelden
 
HomeLibraryDownloadsSupportWebcasts & EventsCommunityForenBlogs
Ressourcen für IT-Professionals >
> 
> 
Programmatic file I/O loses consistency when DFS-R enabled

Frage Programmatic file I/O loses consistency when DFS-R enabled

  • Dienstag, 21. Juni 2011 13:58
     
      Enthält Code
    Anmelden
    1

    We have encountered a situation where certain programmatic blocking file i/o tasks have lost consistency when accessing/manipulating files being replicated by DFS-R.

    At the most basic level (in .NET, in case it matters):

     

    File.Delete(filepath); // --> my understanding is that this should block until the operation completes
File.Exists(filepath); // --> returns true (should logically be false)
Thread.Sleep(1000); // wait a second
File.Exists(filepath); // --> returns false

    This situation seems to occur ONLY when DFS-R is enabled (all other variables accounted for).

    Our setup: Application accesses file share \\fileserver\sharename. File server is Windows 2008 R2 that has a SAN mapped to a local drive which is shared. File server also has DFS-R enabled (not namespaced) with replication set up for another location over WAN.

    Not sure if this is a .NET issue or a DFS-R issue (or something else), so trying to approach it from both ends.

     

Alle Antworten

  • Dienstag, 30. Oktober 2012 16:19
     
     
    Anmelden
    1
    We are seeing this same exact issue on Windows Server 2003 R2 as well. When DFS-R is under high load, the File.Exists(filepath); can return true after a delete call is made. It seems to be rare and only when the system is under high load. Did you ever find a solution to this?
     
  • Freitag, 30. November 2012 21:15
     
     
    Anmelden
    1
    We are seeing this same exact issue on Windows Server 2003 R2 as well. When DFS-R is under high load, the File.Exists(filepath); can return true after a delete call is made. It seems to be rare and only when the system is under high load. Did you ever find a solution to this?

    I have the exact same issue.

    -Tony