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    [W:0.022 / U:61.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site