>Can't remember what was the reasoning behind the recomendation to turn write-behind caching off on a VFP file-server (and workstation?).
>Is it still there? For all OS?

I think this depends on one's personal experiences. If you've ever suffered data loss which you think was caused or exacerbated by write-behind caching you'll think it's the devil incarnate.

On the other hand, never having had that experience myself, my preference is to leave write-behind caching enabled for both servers and workstations, assuming the following:

For servers:
- NT4 or better OS
- History of reliable operation i.e. hardware and drivers
- Professional-grade UPS in place and tested regularly

For workstations:
- Windows 98 Second Edition, or NT4 or better OS (no Windows 95 or Me)
- History of reliable operation i.e. hardware and drivers
- Important data not stored to local hard drive(s). For example, many multiuser VFP apps write only temporary files to the local HD
- UPS recommended if non-VFP apps, or local VFP apps write important data to local drive(s).

Write-behind caching improves performance, not just of the disk subsystem but usually of the system as a whole because in many cases the disk subsystem is the performance bottleneck of the entire computer. It becomes more important as disk subsystems are more heavily used and as the difference between CPU/RAM speed and disk speed increases. Both of these conditions are found in modern file servers: fast CPU(s), tons of RAM and disks that get hammered hard.

Many times, these servers are also running SQL Server, Exchange Server, maybe other intense processes as well. These are likely to be just as mission-critical as your VFP LAN app. If you turn off write-behind caching on the server, these apps will suffer as well; the network admin is not likely to look favourably on it, especially if the company has invested big bucks in a high-performance disk subsystem.

The above arguments can also be applied to workstations, although the performance gains are usually less because they are usually less heavily loaded. On the other hand they may have relatively slow hard drives, which would raise write-behind caching's performance gains.

As I see it, on any single computer write-behind caching is just part of the memory/virtual memory/disk subsystem interplay that goes on behind the scenes in all Win32 OSs. Caching in general is well-understood and, to give it its due, well-implemented in all modern OSs. All modern CPUs employ caching, in up to 3 levels and no-one ever thinks twice about it, let alone demands to turn it off. All modern hard drives have , at the very least, hardware track read buffers that cannot be disabled.

My experiences leaving write-behind caching enabled have been uniformly positive. Maybe that's because I build my own systems with quality components, update BIOSs and drivers and apply OS patches and SPs when available. I'm a big believer in UPSs; I've run all my workstations and servers, plus hubs, routers and broadband modems on them since 1995. My systems are reliable. The decision on whether your systems are "reliable enough" to support write-behind caching will be entirely up to you.

Based on my experience as both a network admin and VFP developer I'd rate a number of issues ahead of write-behind caching in importance (i.e they need to be fixed or they'll cause multiuser VFP app issues):

- Server misconfiguration (e.g. incorrect DNS setup which has surprisingly far-reaching effects)
- Unresolved server problems e.g. event logs that are not "clean" and are allowed to fester rather than addressing the problems
- Server patches and updated hardware drivers not applied leading to app crashes or BSODs
- Overly aggressive antivirus on both server and workstations
- Spyware on workstations hooking into the IP stack and causing network unreliability
- Substandard network cabling - bad end connectors, trying to run 100BaseT on Cat3 or Cat4 cabling, etc.
- Lack of UPSs on critical computers, and on hubs/switches routers that also have to keep running in the event of a power outage. Dirty power also causes a lot of soft errors in computer hardware
- Opportunistic locking set inappropriately for the network environment. IMO reliable implementation of oplocks requires reliable computers at all locations and UPSs on ALL computers plus network infrastructure like hubs, switches etc. Unfortunately, oplocks are on by default at both server and WS. File and record lock synchronizing, and network redirector data cache coherency across a LAN have many more potential points of failure than the disk subsystem in any single computer so I'd be inclined to go "conservative" on oplocks before doing so on write-behind caching.