FreeBSD errors on new dir code

[Jeremy Allison]

On Fri, Jan 28, 2005 at 11:06:11PM -0800, Jeremy Allison wrote:
> On Sat, Jan 29, 2005 at 05:40:34PM +1100, Andrew Bartlett wrote:
> > The build farm is doing it's job, is some sense I suppose..
> > 
> > I got a lovely e-mail, that one of our new build farm machines has
> > uploaded a 240MB log file, filled at least partially with:
> > 
> > WakeDir: in path LISTDIR. offset changed 2002 -> 1
> > WakeDir: in path LISTDIR. offset changed 2003 -> 1
> > WakeDir: in path LISTDIR. offset changed 2003 -> 1
> > 
> > This is from the DIR1 test.
> 
> Ok, so I'm not asleep yet :-). I've just tested this on my
> Fedora Core 2 box and I don't get this message.....
> 
> Hmmmm. Only on FreeBSD ? I wonder if tridge has tested
> the Samba4 code on FreeBSD ?

This is the source of the offending error message :

        if (offset != dirp->offset) {
                SMB_VFS_SEEKDIR(dirp->conn, dirp->dir, offset);
                dirp->offset = SMB_VFS_TELLDIR(dirp->conn, dirp->dir);
                if (dirp->offset != offset) {
                        DEBUG(0,("WakeDir: in path %s. offset changed %ld -> %ld\n",
                                dirp->dir_path, offset, dirp->offset ));
                        return -1;
                }
        }

It means a seekdir(offset) followed by a telldir(offset)
is returning a different value. Checking in the FreeBSD
man pages I find :

     The telldir() function returns the current location associated with the
     named directory stream.  Values returned by telldir() are good only for
     the lifetime of the DIR pointer, dirp, from which they are derived.  If
     the directory is closed and then reopened, prior values returned by
     telldir() will no longer be valid.

This is not neccesarily the case in the new directory code (ie.
we are saving telldir values, and closing and reopening the directory
and reusing the old values with seekdir).

Fixing this assumption may make the directory code slower on
FreeBSD (no name cache allowed - this also breaks the OS/2
delete code). I'll think about this some more.

Tridge, it looks like we have our first system where the problem
we discussed will occur.

:-(.

Jeremy.