samba - Jan 1999 - Locally cached files

I've just upgraded our little network here to 2.0 beta 5.  The server is a 
Data General Intel box running DGUX R4.20.

Compile and install went incredibly well and things have just about 
working straight off.

However, we experienced a little 'funny' this afternoon.

A user was creating and deleting a postscipt file in a Unix directory.
She then used Ghostview on the PC client to view this postscript file. All 
went well the first time, but when she deleted and recreated the file in 
Unix and tried to reread it in Ghostview on the PC, she still got the 
previous version of the file.

It is obvious that the PC has cached the file locally and is not seeing the 
new version.  Indeed, she only saw the new version when she rebooted 
her PC!

On all shares I am using the default 'oplocks = true'.  Does oplocks
cause
this kind of local caching?  If so, I thought switching off 'oplocks'
was
"bad".  Are there any other parameters that might be causing this?

Here are the relevant sections from the smb.conf:

[global]
   server string = Craymer's Samba server
   debug level = 2

   security = user

   guest account = guest
   guest ok = no
   read only = no
   create mask = 0775

   workgroup = MCCARTHY
   wins support = yes
   domain master = yes
   local master = yes
   preferred master = yes
   os level = 65

and the share is:

[pc]
   comment = PC directory
   path = /pc
   writable = yes

Any help would be greatly appreciated.


Cheers,

Duncan Kinnear,
McCarthy and Associates,			Email:  duncan@McCarthy.co.nz
PO Box 764, McLean Towers,			Phone:  +64 6 834 3360
Shakespeare Road, Napier, New Zealand.		Fax:    +64 6 834 3369
-------------------------------------------------------------------------------
Providing Integrated Software to the Meat Processing Industry for over 10 years

You wrote:
A user was creating and deleting a postscipt file in a Unix directory.
She then used Ghostview on the PC client to view this postscript file.
All 
went well the first time, but when she deleted and recreated the file in 
Unix and tried to reread it in Ghostview on the PC, she still got the 
previous version of the file.

	This is a side-effect of oplocks, as you suspected. There are several
	ways of addressing it:
	1. Turn of oplocks on the file (veto oplocks = thisfile/thatfile)
	2. Turn of oplocks on the share (oplocks = no)
	3. Break the lock when recreating the file (this causes
	   the client to clear it's cache).

	The latter can be done by updating the file with either
	smbclient or smbsh, and I suspect that it would be fairly
	easy to write an 'smbtouch" script that triggers an oplock.
	As "touch" uses lseek/llseek, and it's wrapped in
source/smbwrappers,
	something like 
	smbsh <<!
	$userid
	$password
	touch $1
	!
	might well do the job.
 
	More properly, LS_PRELOAD=/usr/local/samba/bin/smbwrapper.so touch $1
	would do the job, given $1 as a path rooted in /smb/your-server in each
	case...

	Want to try that and drop me a line?

--dave (avoiding setting up the test client again) c-b
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com