smbfs mounted file, tail -f STILL does not work

[root]

Urban,

Thanks for the reply.

No, "ping -t 127.0.0.1" loops internally (just like ping on linux).  It IS
continuously appending to the file.  I am not re-executing the ping command
each time, I'm EXECUTING IT ONCE and letting it continuously append to the
file.  The "program > file" will take all output from a single execution and
write it to file.  The "program >> file" appends each separate execution to
the file, but remember --- that will not work here because while tail is
running against the target file it is LOCKED on the NT side.  "program >>
file" would get a sharing error.

So, back to the original problem:

I have tried this many different ways.  There is DEFINATELY a problem with
smbfs.  Did you get a chance to read the "More Info" append.  I wrote a
program to tail the file and it is able to read characters from the stream.
The problem is, all characters beyond the "original" end of stream are null
(hex 00), with the occasional exception of a few characters

----- Original Message -----
From: "Urban Widmark" <urban at svenskatest.se>
To: "root" <root at harlantype.com>
Cc: <samba at us5.samba.org>
Sent: Saturday, November 18, 2000 6:58 AM
Subject: Re: smbfs mounted file, tail -f STILL does not work


> On Fri, 17 Nov 2000, root wrote:
>
> > 1) start appending to a local NT file from a process running on the NT
> > box (I used ping -t 127.0.0.1 > temp.txt)
>
> Does 'ping -t 127.0.0.1 > temp.txt' really append to temp.txt? Does it not
> (for each run) truncate and rewrite the file, just as tail -f on the linux
> side says?
>
> I don't have an NT-box handy, but in dosemu
> % echo hej > aa
> % echo hej > aa
>
> Generates a file containing only one "hej".
>
> % del aa
> % echo hej > aa
> % echo hej2 >> aa
>
> Generates a file with "hej" and "hej2". Does > vs >> make any difference
> for you?
>
>
> > Also, if you append to the NT file from the linux box then tail DOES
> > see the change.  Yet another also, if you break and then restart the
> > appending process on NT (keeping the linux tail running) then the NT
> > box reports: "The process cannot access the file because it is being
> > used by another process".  Seems like there is also a locking problem
> > (I tried mounting the filesystem "ro" but that did not help either).
>
> There are locking problems with smbfs. It sort of doesn't implement
> locking at all ... smbfs opens all files read-write, that may be what is
> blocking access for the other process.
>
> ro-mounts does not help, it still makes the same call to the other side.
>
> /Urban
>