File cacheing problem?

Richard Harvey Chapman hchapman at 3gfp.com
Fri May 4 18:03:53 GMT 2001


Well, having reread your e-mail, my first answer (below my signature) is
not for you, but it may apply. A samba book I was reading indicated to me
that when more than one machine edits concurrently the same file on a
share, the only way to keep them in sync is to have both machines access
the file via SMB. So perhaps, mounting the share on the windows box and
editing it through the network mount will work. I know this seems silly,
but it might work.

However, it would be nice to know of a better solution.

R.


I had this same problem. Although, I was working the other way around:
editing under linux and compiling under windows.

Anyway, you probably need to look into the oplock settings. If I recall
correctly, oplocks (Opportunity Locks) allow a client to lock a file for
writing. This basically guarantees that no one else will be allowed to
write to the file so the client can feel free to cache the file locally.
Turn oplocks off for the share you're having trouble with and your
caching problems should go away.  BTW There are multiple settings for
oplocks.

On Fri, 4 May 2001, James H. Puttick wrote:

> I have a Linux box (Pentium III processor, 256M RAM) running
> kernel version 2.4.3, and smbmount version 2.0.7. The Linux box has
> a Windows 2000 Server share mounted via "mount -t smbfs ...".
>
> I am running into what seems to be a cacheing problem. I am doing
> software development on this share, editing the files from a Win98
> workstation, and compiling on the Linux box.
>
> However, frequently, if I edit a file, make a few small changes (so that
> the size of the file changes by a few dozen bytes or less), and then
> recompile, Linux gets a corrupt version of the file. Suppose I've
> increased the file length by 20 bytes. I will get the *old* version of the
> file, but then padded out to the correct length with 20 nullchars at the
> end.
>
> When this happens, I've found the following seems to force Linux to
> get a correct copy: delete a big chunk of the file, save it (from
> Win98), reread it from Linux, put the big chunk back, and then reread
> it again.
>
> I used a network sniffer to monitor the packets. What I found is that,
> when the problem occurs, Linux sends SMB requests to query the
> path info for the file and open the file, but does not actually reread the
> file.
>
> My conclusion is that either (a) Win2K is providing Linux with the
> information indicating that the file has changed, but Linux is failing to
> recognize that it has to re-read the file, or (b) Win2K is not providing
> that information, so that Linux doesn't realize that the file has changed.
> (But it is odd that Linux *does* know that the length has changed.)
> Unfortunately, I don't know enough about SMB protocol to
> determine where the fault is.
>
> I don't know if timestamps are relevant, but the Linux box uses NTP
> to maintain the same time as the Win2K machine; and the Win98
> machine is within a second of the same time.
>
> Suggestions?
>
> Also, is there a way to force SMB to dump its cache and reread the
> file, other than unmounting and remounting the share?
>
> Thanks.
>
> -- James
>
>
> ----------------------------------------
> James H. Puttick
>
> Kerr Vayne Systems Ltd.
> 1 Valleywood Drive, Unit 5A
> Markham, Ontario L3R 5L9
> Canada
>
> +1 905 475 6161  office
> +1 905 479 9833  fax
>
> mailto:james.puttick at kvs.com
> ----------------------------------------
>
>





More information about the samba mailing list