samba - Jun 2004 - locks on read-only files from windows share?

*** Authentication Certificate ***

We are reasonably sure that until recently we could do a "tail -f" on
a
file on a share from windows mounted on linux 2.4x (samba 2.2+), and
processes on windows had no problem writing to that file while we saw the
output scroll in the tail.

We suspect some Windows OS patch recently changed this behavior, so that
now any windows process fails to write to that file, with a sharing
violation error.  This happens on XP, 2K, & 2K3 using samba 2.2 or samba
3.0.2.   The freeware utility tail for windows does NOT have this problem
when it is doing "tail -f" across a share.

I have already tried the CIFS back-port for 2.4.  In this case, there is no
sharing violation, but also "tail -f" no longer works - and does not
update
the file as it is written to on windows.  Pretty much defeats the purpose!

Kyle

On Wed, Jun 30, 2004 at 03:25:19PM -0600, Kyle Davenport
wrote:
> *** Authentication Certificate ***
> 
> We are reasonably sure that until recently we could do a "tail
-f" on a
> file on a share from windows mounted on linux 2.4x (samba 2.2+), and
> processes on windows had no problem writing to that file while we saw the
> output scroll in the tail.
> 
> We suspect some Windows OS patch recently changed this behavior, so that
> now any windows process fails to write to that file, with a sharing
> violation error.  This happens on XP, 2K, & 2K3 using samba 2.2 or
samba
> 3.0.2.   The freeware utility tail for windows does NOT have this problem
> when it is doing "tail -f" across a share.
> 
> I have already tried the CIFS back-port for 2.4.  In this case, there is no
> sharing violation, but also "tail -f" no longer works - and does
not update
> the file as it is written to on windows.  Pretty much defeats the purpose!
Can you give me an exact mechanism to reproduce this. I'll need
to know the clients/servers involved and also the smb.conf parameters.
Note that no more updates are being done for 2.2.x, so see if you can
reproduce this with 3.0.x first.

Thanks,

	Jeremy.