Managing NFS and NIS, 2nd Edition - Mike Eisler [133]
C> type h:\test.txt
This is a line
of text without carriage returns
In this example, you need to convert file test to Windows format before reading it on the PC/NFS client. The conversion entails the addition of carriage returns (CTRL-M characters) to the end of each line and adding an end-of-file marker (CTRL-Z) to the end of the file.
You can put Windows files of any sort — executable, binary, or text — on a Unix fileserver and access them using normal Windows mechanisms. PC/NFS doesn't care about the content of the files. The file format conversion problem exists only for text files that were created on one system that must be read on another. If you put a Windows binary on a Unix NFS server, it will not require any format conversion to be read and executed by the PC/NFS client.
Text file conversion utilities are available on Unix as well. Solaris has unix2dos and dos2unix. Linux has mcopy.
* * *
[3] The same is true when using a Unix NFS client with AUTH_SYS.
Printer services
PC/NFS lets you access a printer attached to a Unix host by redirecting printer output to a file on the PC/NFS print host. It's up to the server to spool the file to the printer, using the standard Unix lpr or lp mechanism. There's no requirement that the Unix printer be directly attached to the print host; if the server has to print remotely, it does so transparently to the PC/NFS client.
The PC/NFS print and authentication functions are performed by the same machine: both services are handled by the PCNFSD daemon that runs on the authentication server. You may choose to run PCNFSD daemons on several NFS servers to separate the authentication and printing services. PC/NFS clients will send requests to PCNFSD daemons used for printing if the PC printer definitions explicitly name the print host.
Note that some PC/NFS implementations support printing via the LPR protocol, thus obviating the need to run the PCNFSD daemon if it is not needed for authentication and permissions checking purposes.
Chapter 11. File Locking
In Section 7.5, we introduced the concept of file locking and the two primary components: the RPC lock daemon and the status monitor. This chapter will delve more deeply into file locking and will examine the administrative aspects.
What is file locking?
File locking is the act of ensuring that when you access a file, usually via a software application, no one can change the file until you are done examining it. If you want to modify the file, then file locking ensures that no one else can examine or modify the file until you are done modifying it.
The earliest versions of Unix had no way to lock files except to create lock files. The idea is that two or more processes would more or less simultaneously try to create a lock file in exclusive mode, via the O_EXCL flag of the open( ) system call. The operating system would return success to the process that won the race, and a "file exists" error to losing processes. One problem with this scheme is that it relies on the winning process to remove the lock file before it exits. If the process is running buggy software, this might not happen. Some applications mitigate this problem by recording the process ID of the winner into the contents of the lock file. A process that finds that it gets a "file exists" error can then read the lock file to see if the owning process is still running.
Still, lock files can be clumsy. In the 1980s, Unix versions were released with file locking support built into the operating system. The System V branch of Unix offered file locking via the fcntl( ) system call, whereas the BSD branch provided the flock( ) system call. In both cases, when the process that creates the lock dies, the lock will be automatically released.
Exclusive and shared locks
Both fcntl and flock give the choice of either an exclusive lock, where only one process could hold the lock, or a shared lock, where multiple holders