Editor's Forum
File systems are obviously at the core of much of what we do with computers, whether we are wearing our user hat or our admin hat. As users, file systems allow us to store the fruits of our computing efforts, neatly organized so we can quickly find what we need, and structured in a way that we can share the files with appropriate other users. As administrators, the management of file systems is the most basic of our system administration activities. File systems are what we back up every night, and what we restore when the need arises. They are also the focus of much of our system-tuning activities. Additionally, we monitor them to make sure they don't get too full, audit them for appropriate file permissions, and scan them for files containing various forms of security risks. In today's heterogeneous environment, however, it is surprising how much file systems have to do with our system integration efforts. File systems, after all, have been around since the beginning of computers. Although the media that support them have undergone dramatic changes through the years (from punch cards to relatively tiny, high-capacity disk drives, for example), and various technologies have been invented for different types of file system usage, the basic elements of a file system have not changed much. In addition to the data, the basic elements of a file system include ownership and access permissions, bit-level information about the physical location on the media, and potentially a few more juicy tidbits relating to encoding and the like. In general, however, encoding information is usually considered part of the data, thus keeping the file system itself neutral to such fine points. UNIX vendors, even while promoting their own implementation of the operating system, figured out that they all needed to support each other's file systems in a OS-neutral manner. Network-based file-sharing and file-access protocols easily deal with the variations between different file systems. Such protocols even deal with big-endian versus little-endian issues in all but the most severe cases. All that is thanks to the open standards process where everyone had a voice in the definition of the specification. That process even left room for innovation. Various UNIX vendors and third-party ISVs, for example, supply logical volume managers that provide greater administrative flexibility to the file systems. Thus, it is a source of amazement to me that so many of our integration issues deal with desktop-related file system problems. We have essentially four desktop file systems: FAT16 for MS-DOS and Windows 3.x, FAT32 for Windows 9x, NTFS for Windows NT, and MacOS. None are compatible among themselves or with UNIX, although Apple has included the ability to read DOS and Windows diskettes for several years. And, yes, Samba allows UNIX systems to access Microsoft-based file systems, and NFS allows Windows machines to mount UNIX file stores. But, there is little in the native Microsoft operating systems that affords compatibility with anything other than the same Microsoft operating system. How could a vendor of a supposedly open operating system forget to include such rudimentary file system features? Even among its own operating systems? Could it be that MacOS and UNIX files are so evil that desktop users need to be protected from them? Or, could it be that Microsoft (the non-monopoly according to one participant in a recent Washington, D.C. meeting) is actually using its position of market dominance to make it difficult for us to use anything except Microsoft products? No. Surely they wouldn't do that.
Sincerely yours, |