Date: Sat, 28 Oct 2000 20:17:35 +0100 From: Peter Edwards <peter.edwards@openet-telecom.com> To: Trent Nelson <tpnelson@echidna.stu.cowan.edu.au>, David van Deijk <d.d.v.deijk@student.tue.nl>, freebsd-hackers@FreeBSD.ORG Subject: Re: dir-listing bug in linux-emulation Message-ID: <39FB264F.EEFB5AE1@openet-telecom.com> References: <39F82D3C.2532AEB7@student.tue.nl> <39F8F53C.A500A16B@echidna.stu.cowan.edu.au> <39FAF500.526FFD69@openet-telecom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm,
It appears, on second look, a little more complex. The cookies are used
properly in most places, but the fix was introduced in 1.36 breaks it.
I understand what's going on now, and I'll try a for a more complete
patch... Watch this space!
--
Peter.
Peter Edwards wrote:
>
> Hi,
> Here's a patch that fixes the problem for me. can someone review and
> possibly commit it?
>
> Here's my understanding:
>
> The data returned by VOP_READDIR is not neccessarily the same as that
> consumed from the directory vnode.
>
> linux_getdents fills in a "doff" field in the linux_dirent structure
> using the offset from the start of the read data rather than the offset
> in the directory vnode that produced that directory entry.
>
> Then, rather than continuing where it left off, the linux "ls" command
> uses this as an offset to seek to before the next time it calls
> linux_getdents, (actually seeking back over data it's already read, for
> some reason).
>
> The correct offset is provided via the VOP_READDIR "cookies" when
> available. For the code-path that I can produce, the following patch
> makes linux's ls work on my -stable box for ufs, cd9660, and msdos
> filesystems.
>
> diff -c -r1.38.2.2 linux_file.c
> *** src/sys/i386/linux/linux_file.c 2000/07/19 21:12:39 1.38.2.2
> --- src/sys/i386/linux/linux_file.c 2000/10/28 15:21:35
> ***************
> *** 498,504 ****
> linux_dirent.doff = (linux_off_t) linuxreclen;
> linux_dirent.dreclen = (u_short) bdp->d_namlen;
> } else {
> ! linux_dirent.doff = (linux_off_t)(off + reclen);
> linux_dirent.dreclen = (u_short) linuxreclen;
> }
> strcpy(linux_dirent.dname, bdp->d_name);
> --- 498,504 ----
> linux_dirent.doff = (linux_off_t) linuxreclen;
> linux_dirent.dreclen = (u_short) bdp->d_namlen;
> } else {
> ! linux_dirent.doff = (linux_off_t)(cookiep ? *cookiep :
> off+reclen);
> linux_dirent.dreclen = (u_short) linuxreclen;
> }
> strcpy(linux_dirent.dname, bdp->d_name);
>
> I'm not sure about the "justone" case: I'll have to read the code more
> carefully, since I can't get this code to execute without an older linux
> "ls".
>
> Trent Nelson wrote:
> >
> > David van Deijk wrote:
> > >
> > > Dear hackers.
> > >
> > > When I was running an linux program (soffice) i needed something of my
> > > dos-partition.
> > > Then i stumbled onto something I would call a "major" bug.
> > >
> > > I went to /dos/c (my first partition ) but saw only 6 files and 1 dir.
> > > So i went for some exploring and this are my results:
> >
> > > PS. any other persons confirming (or not) this problem would be
> > > welcome.
> >
> > Yup, I had the exact same problem running Star Office 5.2 in
> > 5.0-current.
> >
> >
> > Trent.
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39FB264F.EEFB5AE1>