--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Dear folks,

i've been puzzled a bit by a wierd offset i get in UDF's VOP_READDIR() that 
specific calls to getdents() generate when used by shells for globbing etc.

A breakpoint tracked it back to compat_30_sys_getdents. There i read that 
the value of `ncookies' as returned by the VOP_READDIR() is not used at 
all. Also the function *demands* NFS support or a dirent stream to be 
called again by the sum of all dirent lengths.

Since my UDF implementation doesn't grok NFS yet it got bitten by that. Now 
i dont know why this assumption is made for the VOP_READDIR itself updates 
the uio with the new offset to be callable again wich normally goes OK.

So should the compat's getdents code
1) honour the ncookies returned?
2) use the auio.uio_offset for the next call/batch ?

With regards,
Reinoud


--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ7bJeIKcNwBDyKpoAQIpMwf9EkEeIFMeDNdXPmdn5QpjHvFQMIOpHxkR
QQRTo2bX/kbYZpuuz9cJICuBK4RE38/6yvDttqDb/qmJ5fhOf/nO7xBXhZutoYy7
GT86+qJu/+4Qc8ps+oWINoj144JzpEe89hrLzBbnCQ3SQt7CwWfJ7S2LHh94jMnZ
kkkS6AcvkSac94zqf6EC/ncL6GBVKSaVQRJJ+eWcACVtpSgs0ZkF/yufyBrpt7De
y+1d0JCQtQ/o9yYbpmppsWnqmjcpF9zZuLvmrr4+lr5ogo5QFnMY/LtERQOjmNpC
4r1cSjP8en6xn9hQJuD4Hlsq2cWVq7JppXX0g4PnpmK2nIya0PWXeA==
=TnuT
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--