Messages in this thread | | | Date | Mon, 16 Dec 1996 12:53:45 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Proposal: restrict link(2) |
| |
From: "Andrew E. Mileski" <aem@ott.hookup.net> Date: Fri, 13 Dec 1996 15:52:34 -0500 (EST)
> Since this is a quota issue, let's just focus on that: If QUOTA's are > enabled, we restrict hard link to the owner. Otherwise quota is non-viable.
This is the first reasonable thing I've read in this thread. Will everyone please make your opinion of THIS IDEA known, or present an alternative (ie. let's get on with it).
There are programs that use link to a file as a way of doing file locking. This is a time-honored Unix technique, which avoids assuminig that OS's have correctly implemented flock() and fcntl(), and/or for remote filesystems (read: NFS) where flock() or fcntl() aren't necessarily gauranteed to work. By changing the semantics of link(), you will break some programs that have been very carefully written to be portable to as many Unix systems as possible, including non-POSIX systems.
The real qualm which I've heard is the quota issue, and the "rm --truncate" idea seems to be the best way of solving that problem. The second-best way is one where if a user notices that their quota doesn't go down, they complain to the sysadmin, which manually runs "find" as root, expunges the file, and then (if necessary) expunges the user who made the hard link.
BTW, this is not a new problem. Time-sharing BSD systems have had this property for a very long time (over a decade), and people have survived.....
- Ted
| |