--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 31, 2004 at 02:02:21PM -0700, Aaron J. Grier wrote:
> On Mon, May 31, 2004 at 10:03:23AM +0000, Martin J. Laubach wrote:
> > |  bash-2.05b# mkdir -p foo/foo/foo
> > |  bash-2.05b# rm -rf foo
> > |  rm: foo/foo: Operation not permitted
> > |  rm: foo: Directory not empty
> >=20
> >   I just tried from my OS-X box to my 1.6 file server:
> >=20
> > [celery:~/asparagus] mjl% mkdir -p foo/foo/foo
> > [celery:~/asparagus] mjl% rm -rf foo
> > [celery:~/asparagus] mjl%=20
> >=20
> >   So at least it doesn't look as if it were a server side bug?
>=20
> it's more of a base incompatibility between differing implementations.
>=20
> http://mail-index.netbsd.org/current-users/2004/05/25/0013.html
>=20
> the microsoft NFS server apparently expects the client to perform the
> recursion necessary to support rm -r, and the NetBSD NFS client isn't
> properly handling that case.
>=20
> I imagine the checks necessary for client-side recursion could be added;
> perhaps there's already existing hooks for it?

Uhm, no. That's not the problem. While there is a problem in the client,=20
it is not "the client's not handling how the Windows server works." As I=20
noted previously, My 1.6 and 1.6ZK NFS clients get this scenario right;=20
they issue all the correct remove calls.

Take care,

Bill

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

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

iD8DBQFAvNvpWz+3JHUci9cRAmzeAJ48aeLlyYJgs8WK7lvzrjuLdvzvoQCeOmX1
iSnCNrxX7eCslfS/NVhiEQo=
=SFwW
-----END PGP SIGNATURE-----

--ZPt4rx8FFjLCG7dd--