Lines Matching refs:rename
25 4) rename() that is _not_ cross-directory. Locking rules: caller locks
43 6) cross-directory rename. The trickiest in the whole bunch. Locking
74 (1) if object removal or non-cross-directory rename holds lock on A and
76 acquire the lock on B. (Proof: only cross-directory rename can change
79 (2) if cross-directory rename holds the lock on filesystem, order will not
80 change until rename acquires all locks. (Proof: other cross-directory
104 Any contended object is either held by cross-directory rename or
106 operation other than cross-directory rename. Then the lock this operation
109 It means that one of the operations is cross-directory rename.
112 own descendent. Moreover, there is exactly one cross-directory rename
115 Consider the object blocking the cross-directory rename. One
116 of its descendents is locked by cross-directory rename (otherwise we
118 means that cross-directory rename is taking locks out of order. Due
120 But locking rules for cross-directory rename guarantee that we do not
126 the only operation that could introduce loops is cross-directory rename.
127 Since the only new (parent, child) pair added by rename() is (new parent,
129 would have to exist before rename(). I.e. at the moment of loop creation
130 rename() responsible for that would be holding filesystem lock and new parent
133 we had acquired filesystem lock and rename() would fail with -ELOOP in that
139 also preserved by all operations (cross-directory rename on a tree that would