From bd34c2ac25af690a00cbbded5b57a834a4e35875 Mon Sep 17 00:00:00 2001 From: Jeremy Allison Date: Fri, 27 Jan 2006 23:30:30 +0000 Subject: r13198: Fix issues exposed by Jerry's testing on 64-bit Solaris (I hope). Separate 3.0.21b patch sent to Jerry. Jeremy. (This used to be commit 837e7ea7e40cedc6b01e023445feb4a90c4bf8b9) --- source3/locking/locking.c | 22 ---------------------- 1 file changed, 22 deletions(-) (limited to 'source3/locking') diff --git a/source3/locking/locking.c b/source3/locking/locking.c index be1e83121b..e31ead30e4 100644 --- a/source3/locking/locking.c +++ b/source3/locking/locking.c @@ -988,28 +988,6 @@ BOOL downgrade_share_oplock(struct share_mode_lock *lck, files_struct *fsp) return True; } - -/******************************************************************* - We've just told all the smbd's that our level2 or fake level2 has been - written to. -********************************************************************/ -BOOL remove_all_share_oplocks(struct share_mode_lock *lck, files_struct *fsp) -{ - int i; - for (i=0; inum_share_modes; i++) { - struct share_mode_entry *e = &lck->share_modes[i]; - if (!is_valid_share_mode_entry(e)) { - continue; - } - if (e->op_type == NO_OPLOCK) { - continue; - } - e->op_type = NO_OPLOCK; - lck->modified = True; - } - return True; -} - /**************************************************************************** Deal with the internal needs of setting the delete on close flag. Note that as the tdb locking is recursive, it is safe to call this from within -- cgit