lkml.org 
[lkml]   [1996]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site