Dneska přišlo mailem, tak to rovnou hodím na web, protože se jedná o poměrně častou a přitom velmi zajímavou otázku.
Na Windows XP a Windows 2003 a starších se to nestávalo - tedy krom podivných případů, pokud jste měli zapnuty Offline Files a kdoví jaká online detekce nefungovala. Jde nám zde o klienty s Windows Vista a novějšími, kteří se pomocí SMB 2.0 připojují na souborové servery s Windows Vista a Windows 2008 a novějšími. Jenom za takové situace se použije SMB 2.0. Pokud se například i Windows 7 připojují na Windows 2003 file server, stejně to sklouzne na starší SMB 1.0.
Novinkou ve Windows Vista a Windows 7 je SMB 2.0 a ve Windows 8 dokonce SMB 3.0. Toto nové verze a jejich implementece přidaly různé keše na stranu klientů. Nemyslím teď keš obsahu souborů (to se jmenuje Offline Files), ale jen informací o atributech souborů a výpisy adresářů a informace o tom, že soubor neexistuje. Takže vlastně "jen" metadata.
Dokumentace a registrové hodnoty na vylepšení případně vypnutí té keše jsou zde.
Projevy keše
Dva základní projevy, které čas od času můžete pozorovat, nastávají v okamžiku, kdy jste do nějakého sdíleného adresáře (shared folder) z jednoho počítače přidali nějaký nový soubor a snažíte se ten soubor otevřít z jiného počítače. Pokud jste se z toho druhého klienta už na obsah sdíleného adresáře (shared folder) předtím dívali, nebo se ten soubor snažili otevřít, možná vám to bude i nadále říkat, že soubor neexistuje.
- prohlížíte si výpis obsahu sdíleného adresáře a přitom tam ten soubor ještě nevidíte (tady to asi nic nehlásí, jenom ten soubor nevidíte)
- nějaký program se snaží přistoupit do konkrétního souboru, který tam před chvilkou ještě nebyl a pořád to ještě nejde (v takovém případě by to hlásilo File Not Found)
Proč to má smysl?
Mnoho programů zkouší existenci souborů ještě předtím, než k nim přistoupí. Test existence je poměrně drahá operace. Drahá na počet paketů, nebo lépe řečeno paketových výměn (round-trip) mezi klientem a serverem. SMB protokol je tradičně dost ukecaný a prostě klient musí na druhou stranu poslat hodně paketů a čeká na ně jednotlivé odpovědi. Když máte moc dlouhé prodlevy (zpoždění, neboli latency, tedy dlouhé round-trip-time - RTT) mezi klientem a serverem, může takový test i na ADSL trvat i několik sekund.
Programy, protože mnoho programátorů o problémech SMB a RTT v životě neslyšelo, ty testy dělají opakovaně, klidně v sekvenci desítky těsně za sebou. Takže by to pak trvalo i na rychlejších sítích a pevných linkách.
SMB 2.0 to prostě vylepšilo a pokud soubor jednou nenajde, tak si to pak ještě pár sekund myslí a nechodí zbytečně do sítě.
Ty keše se samozřejmě aktualizují okamžitě na stejném stroji, ze kterého jste tu změnu provedli. Takže problém mají jenom jiné počítače, než ze kterého jste tam ten nový soubor nahrávali. Tady bych jenom dodal, že nevím, nezkoušel jsem, jestli se keš aktualizuje, pokud tam ten soubor hodíte lokálně (jenom přes NTFS) a přitom se do toho sdíleného adresáře dívate přes share a jeho síťovou cestu, i když je to na stejném stroji. Klidně bych si byl ochoten myslet, že i tak se ta keš bude uplatňovat se zpožděním.
Řešení
Jako uživatelé prostě několik sekund počkejte.
Jako programátoři nemůžete počítat s tím, že se soubor na jiném klientovi okamžitě objeví, jakmile ho do shared folder strčíte z jiného počítače. To bude chtít nějakou lepší synchronizaci. Nebo vypnout ty keště v registrech, jenže to není asi dobrý nápad pro aplikačního programátora.